syscalls/request_key03: new test for key instantiation races
Hi!
When I run the test as an ordinary user I got EDQUOT from add_key() from time to time. So we either have to add .needs_root = 1 so that quotas does not apply or change the test to ignore the EDQUOT as well while we are adding the key.
Otherwise the test is OK.
Signature · 2 lines
Cyril Hrubis [email protected]
Quoted 8 lines · Cyril Hrubis
Hi!
When I run the test as an ordinary user I got EDQUOT fromadd_key()from time to time. So we either have to add .needs_root = 1 so that quotas does not apply or change the test to ignore the EDQUOT as well while we are adding the key.Otherwise the test is OK.
Ugh, it seems this happens because the kernel frees space from the quota during an asynchronous garbage collection phase, rather than immediately when the keys are unlinked. That's arguably a bug in its own right, but it's always been like that and for now I guess I'll just make the test ignore EDQUOT.
Eric
Hi!
Quoted 5 lines
Quoted 5 lines
When I run the test as an ordinary user I got EDQUOT from
add_key()from time to time. So we either have to add .needs_root = 1 so that quotas does not apply or change the test to ignore the EDQUOT as well while we are adding the key.
Quoted 7 lines
Quoted 2 lines
Otherwise the test is OK.
Ugh, it seems this happens because the kernel frees space from the quota during an asynchronous garbage collection phase, rather than immediately when the keys are unlinked. That's arguably a bug in its own right, but it's always been like that and for now I guess I'll just make the test ignore EDQUOT.
I guess that this is not that serious since I doubt that anybody will add keys in a tight loop like we do in the tests.
I remeber that we had similar problems with the hugepage poll limits where we had to set the limits to be twice of the actual allocations to avoid failures when allocating and freeing these in a loop.
Signature · 2 lines
Cyril Hrubis [email protected]