Re: [PATCH] KEYS: dispatch key_gc_work to system_wq.

[Jarkko Sakkinen <jarkko@kernel.org>]

On Mon, Oct 26, 2026 at 07:19:01PM +0200, Jarkko Sakkinen wrote:
> On Mon, Oct 26, 2026 at 06:57:22PM +0200, Jarkko Sakkinen wrote:
> > > --- x/security/keys/gc.c
> > > +++ y/security/keys/gc.c
> > > @@ -270,9 +270,8 @@ contended:
> > >  
> > >  maybe_resched:
> > >  	if (cursor) {
> > > -		cond_resched();
> > > -		spin_lock(&key_serial_lock);
> > > -		goto continue_scanning;
> > > +		schedule_work(&key_gc_work);
> > > +		return;
> > >  	}
> 
> I guess I'll to elaborate my fix and this proposal as you gave feedback
> of neither.
> 
> What you wanted to respond to my patch other than nitpicking is probably
> this sequence:
> 
>   key_garbage_collector()
>     synchronize_rcu()
>       synchronize_rcu_normal()
>         wait_for_completion()
>           schedule_timeout()
>             schedule()
> 
> I should have put this to the commit message, and missed also this
> detail.
> 
> So the way I saw this, which could be wrong, is that the workqueue
> lockup would could happen less often as also other threads are scheduled
> preemptively in unbounded queue outside critical sections.

I did test this with fairly large keyrings. I think I'll scrape that
script. That does not mean by any means that the fix is correct at all
but. Please in future also provide context for your alternative
proposals because otherwise they pay no contribution to anything.

I'm not really interested whether I'm right or wrong here but
instead of finding the "truth" aka the correcting reasoning
that leads to a proper fix.

A random diff won't do it.

> 
> What you are doing with early return is at least not right as it 
> corrupts the state. So you should supplement that with something
> that carries it.


Br, Jarkko