[PATCH] keys: use long workqueue for garbage collection

[PATCH] keys: use long workqueue for garbage collection

[Eduard Zateev]

The key garbage collector can wait for RCU grace periods. This can occupy a
normal events worker for a long time and contribute to workqueue lockups.

Queue key GC on system_long_wq because its work may wait for long periods.

Reported-by: syzbot+c15de43f1e7fffbb7b9b@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=c15de43f1e7fffbb7b9b
Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>
---
 security/keys/gc.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/security/keys/gc.c b/security/keys/gc.c
index eda445f815d..b174b8c511b 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -19,6 +19,7 @@ unsigned key_gc_delay = 5 * 60;
  * Reaper for unused keys.
  */
 static void key_garbage_collector(struct work_struct *work);
+/* Key GC may wait for RCU grace periods, so queue it on system_long_wq. */
 DECLARE_WORK(key_gc_work, key_garbage_collector);
 
 /*
@@ -57,7 +58,7 @@ void key_schedule_gc(time64_t gc_at)
 
 	if (gc_at <= now || test_bit(KEY_GC_REAP_KEYTYPE, &key_gc_flags)) {
 		kdebug("IMMEDIATE");
-		schedule_work(&key_gc_work);
+		queue_work(system_long_wq, &key_gc_work);
 	} else if (gc_at < key_gc_next_run) {
 		kdebug("DEFERRED");
 		key_gc_next_run = gc_at;
@@ -85,7 +86,7 @@ void key_set_expiry(struct key *key, time64_t expiry)
 void key_schedule_gc_links(void)
 {
 	set_bit(KEY_GC_KEY_EXPIRED, &key_gc_flags);
-	schedule_work(&key_gc_work);
+	queue_work(system_long_wq, &key_gc_work);
 }
 
 /*
@@ -119,7 +120,7 @@ void key_gc_keytype(struct key_type *ktype)
 	set_bit(KEY_GC_REAP_KEYTYPE, &key_gc_flags);
 
 	kdebug("schedule");
-	schedule_work(&key_gc_work);
+	queue_work(system_long_wq, &key_gc_work);
 
 	kdebug("sleep");
 	wait_on_bit(&key_gc_flags, KEY_GC_REAPING_KEYTYPE,
@@ -322,7 +323,7 @@ static void key_garbage_collector(struct work_struct *work)
 	}
 
 	if (gc_state & KEY_GC_REAP_AGAIN)
-		schedule_work(&key_gc_work);
+		queue_work(system_long_wq, &key_gc_work);
 	kleave(" [end %x]", gc_state);
 	return;
 
-- 
2.55.0

Re: [PATCH] keys: use long workqueue for garbage collection

[Jarkko Sakkinen]

On Sat, Oct 24, 2026 at 06:29:44AM +0200, Eduard Zateev wrote:
> The key garbage collector can wait for RCU grace periods. This can occupy a
> normal events worker for a long time and contribute to workqueue lockups.
> 
> Queue key GC on system_long_wq because its work may wait for long periods.
> 
> Reported-by: syzbot+c15de43f1e7fffbb7b9b@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=c15de43f1e7fffbb7b9b
> Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>

This commit message is not huge selling point for any possible argument.

> ---
>  security/keys/gc.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/security/keys/gc.c b/security/keys/gc.c
> index eda445f815d..b174b8c511b 100644
> --- a/security/keys/gc.c
> +++ b/security/keys/gc.c
> @@ -19,6 +19,7 @@ unsigned key_gc_delay = 5 * 60;
>   * Reaper for unused keys.
>   */
>  static void key_garbage_collector(struct work_struct *work);
> +/* Key GC may wait for RCU grace periods, so queue it on system_long_wq. */
>  DECLARE_WORK(key_gc_work, key_garbage_collector);
>  
>  /*
> @@ -57,7 +58,7 @@ void key_schedule_gc(time64_t gc_at)
>  
>  	if (gc_at <= now || test_bit(KEY_GC_REAP_KEYTYPE, &key_gc_flags)) {
>  		kdebug("IMMEDIATE");
> -		schedule_work(&key_gc_work);
> +		queue_work(system_long_wq, &key_gc_work);
>  	} else if (gc_at < key_gc_next_run) {
>  		kdebug("DEFERRED");
>  		key_gc_next_run = gc_at;
> @@ -85,7 +86,7 @@ void key_set_expiry(struct key *key, time64_t expiry)
>  void key_schedule_gc_links(void)
>  {
>  	set_bit(KEY_GC_KEY_EXPIRED, &key_gc_flags);
> -	schedule_work(&key_gc_work);
> +	queue_work(system_long_wq, &key_gc_work);
>  }
>  
>  /*
> @@ -119,7 +120,7 @@ void key_gc_keytype(struct key_type *ktype)
>  	set_bit(KEY_GC_REAP_KEYTYPE, &key_gc_flags);
>  
>  	kdebug("schedule");
> -	schedule_work(&key_gc_work);
> +	queue_work(system_long_wq, &key_gc_work);
>  
>  	kdebug("sleep");
>  	wait_on_bit(&key_gc_flags, KEY_GC_REAPING_KEYTYPE,
> @@ -322,7 +323,7 @@ static void key_garbage_collector(struct work_struct *work)
>  	}
>  
>  	if (gc_state & KEY_GC_REAP_AGAIN)
> -		schedule_work(&key_gc_work);
> +		queue_work(system_long_wq, &key_gc_work);
>  	kleave(" [end %x]", gc_state);
>  	return;
>  
> -- 
> 2.55.0
> 

Br, Jarkko

Re: [PATCH] keys: use long workqueue for garbage collection

[Jarkko Sakkinen]

On Sat, Oct 24, 2026 at 08:20:55AM +0300, Jarkko Sakkinen wrote:
> On Sat, Oct 24, 2026 at 06:29:44AM +0200, Eduard Zateev wrote:
> > The key garbage collector can wait for RCU grace periods. This can occupy a
> > normal events worker for a long time and contribute to workqueue lockups.
> > 
> > Queue key GC on system_long_wq because its work may wait for long periods.
> > 
> > Reported-by: syzbot+c15de43f1e7fffbb7b9b@syzkaller.appspotmail.com
> > Link: https://syzkaller.appspot.com/bug?extid=c15de43f1e7fffbb7b9b
> > Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>
> 
> This commit message is not huge selling point for any possible argument.

You ignored key_gc_timed_out(), which leaves code to a broken state and
switching workqueue is not solving any possible root cause of anything.
The long queue exists mostly for the sake of flush_workqueue().

Please stop sending patches like this in the future.

Br, Jarkko

Re: [PATCH] keys: use long workqueue for garbage collection

[Jarkko Sakkinen]

On Sat, Oct 24, 2026 at 08:37:42AM +0300, Jarkko Sakkinen wrote:
> On Sat, Oct 24, 2026 at 08:20:55AM +0300, Jarkko Sakkinen wrote:
> > On Sat, Oct 24, 2026 at 06:29:44AM +0200, Eduard Zateev wrote:
> > > The key garbage collector can wait for RCU grace periods. This can occupy a
> > > normal events worker for a long time and contribute to workqueue lockups.
> > > 
> > > Queue key GC on system_long_wq because its work may wait for long periods.
> > > 
> > > Reported-by: syzbot+c15de43f1e7fffbb7b9b@syzkaller.appspotmail.com
> > > Link: https://syzkaller.appspot.com/bug?extid=c15de43f1e7fffbb7b9b
> > > Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>
> > 
> > This commit message is not huge selling point for any possible argument.
> 
> You ignored key_gc_timed_out(), which leaves code to a broken state and
> switching workqueue is not solving any possible root cause of anything.
> The long queue exists mostly for the sake of flush_workqueue().
> 
> Please stop sending patches like this in the future.

Makes me wonder was this even tried a single time TBH given the obvious
glitch.  I would bet for no.

Br, Jarkko