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@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=37ca7ae3e98cb65c3209
> Signed-off-by: Quchaosheng <quchaosheng000406@xxxxxxx>
> ---
> 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