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

From: Hillf Danton

Date: Mon Oct 26 2026 - 18:22:41 EST


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?