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

[Jarkko Sakkinen]

On Tue, Oct 27, 2026 at 06:21:52AM +0800, Hillf Danton wrote:
> On Mon, 26 Oct 2026 19:18:57 +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:
> >
> Nope because synchronize_rcu() has nothing to do with workqueue lockup.
> 
> >  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.
> >
> The unbound queue could also suffer lockup.
> 
> >What you are doing with early return is at least not right as it 
> >corrupts the state. So you should supplement that with something
> 
> How?
>
> >that carries it.
> >
> Feel free to post a diff?

Actually I choose not to answer to your questions as your only
argument is "show the diff" or providing a diff without making
your case. I'm sorry but I don't get anything from this.

If you want to help, be helpful.

Br, Jarkko