[PATCH v2 2/2] kthread: Report cpumask allocation failure without warning

[PATCH v2 2/2] kthread: Report cpumask allocation failure without warning

[Quchaosheng]

kthread_affine_node() warns when zalloc_cpumask_var() fails:

  if (!zalloc_cpumask_var(&affinity, GFP_KERNEL)) {
          WARN_ON_ONCE(1);
          return;
  }

The allocation uses GFP_KERNEL, so it can fail under memory pressure or
fault injection.  A failed allocation is a recoverable condition and not a
kernel bug, so the warning is noise.  syzbot reports it for a WireGuard
NAPI thread:

  WARNING: kernel/kthread.c:359 at kthread_affine_node+0x200/0x2e8
  CPU: 0 PID: 5207 Comm: napi/wg2-0
  Call Trace:
   alloc_cpumask_var_node+0xfc/0x138
   zalloc_cpumask_var
   kthread_affine_node+0x148/0x2e8
   kthread+0x29c/0x3d4
   ret_from_fork+0x10/0x20

The failure is not silent though: the early return also skips
list_add_tail() of kthread::affinity_node, so the thread never joins
kthread_affinity_list and kthreads_online_cpu() will not fix up its
affinity on a later CPU hotplug.  Keep the failure visible with
pr_warn_once() instead of dropping the message.

Reported-by: syzbot+37ca7ae3e98cb65c3209@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=37ca7ae3e98cb65c3209
Signed-off-by: Quchaosheng <quchaosheng000406@163.com>
---
v2:
 - Keep the failure visible instead of dropping the message silently
   (Valentine Schneider, Waiman Long).  A WARN is not appropriate for a
   recoverable GFP_KERNEL allocation failure, but the early return also
   keeps the thread out of kthread_affinity_list, so report it with
   pr_warn_once().

 kernel/kthread.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index a3f95c904..b59fa7c7e 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -356,7 +356,14 @@ static void kthread_affine_node(void)
 		return;
 
 	if (!zalloc_cpumask_var(&affinity, GFP_KERNEL)) {
-		WARN_ON_ONCE(1);
+		/*
+		 * The thread stays out of kthread_affinity_list, so a later
+		 * CPU hotplug will not fix up its affinity. Report it, but do
+		 * not warn: the allocation can fail under memory pressure or
+		 * fault injection, and that is not a kernel bug.
+		 */
+		pr_warn_once("kthread: %s: no cpumask, node affinity not set\n",
+			     current->comm);
 		return;
 	}
 

Re: [PATCH v2 2/2] kthread: Report cpumask allocation failure without warning

[Frederic Weisbecker]

Le Tue, Sep 15, 2026 at 09:42:22AM +0800, Quchaosheng a écrit :
> kthread_affine_node() warns when zalloc_cpumask_var() fails:
> 
>   if (!zalloc_cpumask_var(&affinity, GFP_KERNEL)) {
>           WARN_ON_ONCE(1);
>           return;
>   }
> 
> The allocation uses GFP_KERNEL, so it can fail under memory pressure or
> fault injection.  A failed allocation is a recoverable condition and not a
> kernel bug, so the warning is noise.  syzbot reports it for a WireGuard
> NAPI thread:
> 
>   WARNING: kernel/kthread.c:359 at kthread_affine_node+0x200/0x2e8
>   CPU: 0 PID: 5207 Comm: napi/wg2-0
>   Call Trace:
>    alloc_cpumask_var_node+0xfc/0x138
>    zalloc_cpumask_var
>    kthread_affine_node+0x148/0x2e8
>    kthread+0x29c/0x3d4
>    ret_from_fork+0x10/0x20
> 
> The failure is not silent though: the early return also skips
> list_add_tail() of kthread::affinity_node, so the thread never joins
> kthread_affinity_list and kthreads_online_cpu() will not fix up its
> affinity on a later CPU hotplug.  Keep the failure visible with
> pr_warn_once() instead of dropping the message.
> 
> Reported-by: syzbot+37ca7ae3e98cb65c3209@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=37ca7ae3e98cb65c3209
> Signed-off-by: Quchaosheng <quchaosheng000406@163.com>
> ---
> v2:
>  - Keep the failure visible instead of dropping the message silently
>    (Valentine Schneider, Waiman Long).  A WARN is not appropriate for a
>    recoverable GFP_KERNEL allocation failure, but the early return also
>    keeps the thread out of kthread_affinity_list, so report it with
>    pr_warn_once().
> 
>  kernel/kthread.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index a3f95c904..b59fa7c7e 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -356,7 +356,14 @@ static void kthread_affine_node(void)
>  		return;
>  
>  	if (!zalloc_cpumask_var(&affinity, GFP_KERNEL)) {
> -		WARN_ON_ONCE(1);
> +		/*
> +		 * The thread stays out of kthread_affinity_list, so a later
> +		 * CPU hotplug will not fix up its affinity. Report it, but do
> +		 * not warn: the allocation can fail under memory pressure or
> +		 * fault injection, and that is not a kernel bug.
> +		 */
> +		pr_warn_once("kthread: %s: no cpumask, node affinity not set\n",
> +			     current->comm);

I'm mildy convinced that this is an improvement. The message now becomes easily
missed and appears like any normal information in the logs.

Kthread creation happens mostly on boot and if there is memory pressure already
on boot, the rest is not going to end well anyway.

Thanks.

>  		return;
>  	}
>  
> 

-- 
Frederic Weisbecker
SUSE Labs

Re: [PATCH v2 2/2] kthread: Report cpumask allocation failure without warning

[Quchaosheng]

Hi Frederic,

Thanks for looking at it.

You are right that pr_warn_once() is easy to miss, and that this matters
least at boot under memory pressure. The case I was worried about is the
WARN itself: __warn() taints the kernel and calls check_panic_on_warn(), so
on a box running panic_on_warn=1 a recoverable allocation failure turns
into a panic. That said, the allocation is GFP_KERNEL on a path that runs
once per thread and almost always at boot, so if you would rather keep the
warning as it is, I am fine with that. It is your call and I will not push
it further.

Two things I should mention, since you are the maintainer here:

1. I am not going to re-send this. Waiman said the patch looked good to
   him, but you are the one who would take it, and "mildly convinced" is
   not an ack. If you want a revision with the message kept as WARN, say so
   and I will send one; otherwise please just drop it.

2. This was prepared with an LLM coding assistant and should have carried
   an "Assisted-by: LLM" tag per
   Documentation/process/coding-assistants.rst. It did not, and I am adding
   the tag on anything I send from now on.

Sorry for the extra round trip.

Quchaosheng

Re: [PATCH v2 2/2] kthread: Report cpumask allocation failure without warning

[Frederic Weisbecker]

Le Thu, Sep 17, 2026 at 05:21:16PM +0800, Quchaosheng a écrit :
> Hi Frederic,
> 
> Thanks for looking at it.
> 
> You are right that pr_warn_once() is easy to miss, and that this matters
> least at boot under memory pressure. The case I was worried about is the
> WARN itself: __warn() taints the kernel and calls check_panic_on_warn(), so
> on a box running panic_on_warn=1 a recoverable allocation failure turns
> into a panic.

panic_on_warn=1 can be useful for debugging but I doubt it's ever a good
idea on production though.

> That said, the allocation is GFP_KERNEL on a path that runs
> once per thread and almost always at boot, so if you would rather keep the
> warning as it is, I am fine with that. It is your call and I will not push
> it further.
> 
> Two things I should mention, since you are the maintainer here:

Well I'm not exactly a kthread maintainer, though we all care about that file
and I can do a pull request when necessary, so I'm just giving my opinion here:
I would rather keep the warning because when that allocation fails, something
bad happens that is unrecoverable and that's what warnings are for.

> 
> 1. I am not going to re-send this. Waiman said the patch looked good to
>    him, but you are the one who would take it, and "mildly convinced" is
>    not an ack. If you want a revision with the message kept as WARN, say so
>    and I will send one; otherwise please just drop it.

I don't think it's a necessary change but let's see if others have different
opinions.

> 
> 2. This was prepared with an LLM coding assistant and should have carried
>    an "Assisted-by: LLM" tag per
>    Documentation/process/coding-assistants.rst. It did not, and I am adding
>    the tag on anything I send from now on.

Ah yes please! It's useful for us to know that when we review.

> Sorry for the extra round trip.

No problem, iterations is how we work :-)

Thanks.

-- 
Frederic Weisbecker
SUSE Labs