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

[Jan Stancek <jstancek@redhat.com>]

----- Original Message -----
> Hello,
> 
> 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.

We should probably go with your approach for now: create 2 users ahead,
so at least default case works.

I have difficulty reproducing failure on demand.