generic/581: try to avoid flakiness in keys quota test
authorEric Biggers <ebiggers@google.com>
Wed, 29 Jan 2020 00:42:51 +0000 (16:42 -0800)
committerEryu Guan <guaneryu@gmail.com>
Sun, 9 Feb 2020 15:56:08 +0000 (23:56 +0800)
commit1c5c2aa7f6da46e01663e3c64c7a040fda4224be
tree7994e5a44d09b428a4d49b498323ecc343509055
parent2d4500367c5ed7579fe9f5d396c87b6d669a0c2d
generic/581: try to avoid flakiness in keys quota test

generic/581 passes for me, but Murphy Zhou reported that it started
failing for him.  The part that failed is the part that sets the key
quota to the fsgqa user's current number of keys plus 5, then tries to
add 6 filesystem encryption keys as the fsgqa user.  Adding the 6th key
unexpectedly succeeded.

What I think is happening is that because the kernel's keys subsystem
garbage-collects keys asynchronously, the quota may be freed up later
than expected after removing fscrypt keys.  Thus the test is flaky.

It would be nice to fix this in the kernel, but unfortunately there
doesn't seem to be an easy fix, and the keys subsystem has always worked
this way.  And it seems unlikely to cause real-world problems, as the
keys quota really just exists to prevent denial-of-service attacks.

So, for now just try to make the test more reliable by:

(1) Reduce the scope of the modified keys quota to just the part of the
    test that needs it.
(2) Before getting the current number of keys for the purpose of setting
    the quota, wait for any invalidated keys to be garbage-collected.

Tested with a kernel that has a 1 second sleep hacked into the beginning
of key_garbage_collector().  With that, this test fails before this
patch and passes afterwards.

Reported-by: Murphy Zhou <xzhou@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Murphy Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
tests/generic/581