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

[Jan Stancek]

----- Original Message -----
> Hi Richard
> 
> > The key subsystem independently tracks user info against UID. If a user is
> > deleted and the UID reused for a new user then the key subsystem will
> > mistake
> > the new user for the old one.

Thanks for raising this problem Richard. This matches CKI failure
we seen recently. (CC Li and Rachel)

> Does any documentation or kernel comment mentioned this? I didn't notice
> this before.
> > 
> > The keys/keyrings may not be accessible to the new user, but if they are
> > not
> > yet garbage collected (which happens asynchronously) then the new user may
> > be
> > exceeding its quota limits.
> > 
> > This results in a race condition where this test can fail because the old
> > thread keyring is taking up the full quota. We should be able to avoid this
> > by
> > creating two users in parallel instead of sequentially so that they have
> > different UIDs.
> I guess you may want to creat two user, so next, the key subsystem
> think the new user is different from  the last deleting user. It can
> avoid race.
> 
> But you patch overrides ltpuser, in actually, we still use
> ltp_add_key05_1 in SAFE_SETUID.
> 
> Also, this patch doesn't handle delete user when we using -i parameters.

-i might be problem, but other than that I think it works, at least for default run.

Though I'm wondering, shouldn't the test delete keys it creates,
rather than relying on garbage collection?