[LTP] [PATCH 1/2] add_key05: Avoid race with key garbage collection

Richard Palethorpe rpalethorpe@suse.de
Wed Apr 8 15:36:07 CEST 2020


Richard Palethorpe <rpalethorpe@suse.de> writes:

>>> I'm assuming the keys are 'deleted' when the thread keyring is destroyed
>>> when the child process exits. However they are not freed until later by
>>> garbage collection (maybe I am confusing deferred freeing with 'garbage
>>> collection'?).
>> Do you know how large is the race window?
>> Default /proc/sys/kernel/keys/gc_delay is 300, so if it's tied to this
>> garbage collect, I'd expect it to fail almost all the time.
> It doesn't appear to be tied to that.
>>> We could explicitly delete/revoke the individual keys, but AFAICT there
>>> would still be a race because freeing is still asynchronous. Ofcourse
>>> there might be a reliable way to force freeing?
>> gc_delay is only one I recall.
>> If it's tied to process being around, I can try similar approach from 
>> e747d0456adc ("syscalls/tgkill03: wait for defunct tid to get detached")
>> where we wait for /proc/<pid>/task/<tid> to disappear.
> This might work as the work is scheduled to be done in process context,
> so the task may remain until the keys have been freed.

This doesn't seem to work.

Thank you,

More information about the ltp mailing list