Re: [RFC PATCH 2/6] keys: reclaim link quota during keyring garbage collection

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Oct 16, 2026 at 10:42:44PM -0700, Eric Biggers wrote:
> On Sat, Oct 17, 2026 at 12:53:00AM +0300, Jarkko Sakkinen wrote:
> > Garbage collection removes dead key links without releasing their quota.
> > Repeated collection therefore leaves the owner charged for links that no
> > longer exist, eventually preventing further links with -EDQUOT.
> > 
> > Update the payload reservation from the surviving link count while holding
> > the keyring semaphore. If assoc_array_gc() fails, the tree and its count
> > remain unchanged, so the existing reservation is retained.
> > 
> > Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
> > Assisted-by: LLM
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> >  security/keys/keyring.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/security/keys/keyring.c b/security/keys/keyring.c
> > index 7143f3079d20..db987c891811 100644
> > --- a/security/keys/keyring.c
> > +++ b/security/keys/keyring.c
> > @@ -1755,6 +1755,8 @@ void keyring_gc(struct key *keyring, time64_t limit)
> >  	down_write(&keyring->sem);
> >  	assoc_array_gc(&keyring->keys, &keyring_assoc_array_ops,
> >  		       keyring_gc_select_iterator, &limit);
> > +	key_payload_reserve(keyring,
> > +			    keyring->keys.nr_leaves_on_tree * KEYQUOTA_LINK_BYTES);
> >  	up_write(&keyring->sem);
> >  	kleave(" [gc]");
> 
> This doesn't actually hold a reference to the keyring, so can't it race
> with key_put() which released the quota already?  Then the quota for a
> link can be released multiple times.

I agree. Thanks for checking this. I only got through the first today
but plan to inventory them all in detail.  This can be dropped without
any further consideration.

The head is the LLM assisted part from my side and I go through them
with presumption that the changes are not applicable.

> 
> - Eric

Br, Jarkko