Re: [PATCH 2/2] kthread: Drop warning on cpumask allocation failure in kthread_affine_node()

[Frederic Weisbecker <frederic@kernel.org>]

Le Mon, Sep 14, 2026 at 01:04:22PM -0400, Waiman Long a écrit :
> cc: Frederic Weisbecker <frederic@kernel.org> for his input.
> 
> -Longman
> 
> On 9/14/26 8:09 AM, Quchaosheng wrote:
> > 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 other two callers of zalloc_cpumask_var() in this file, in the kthread
> > preferred affinity and kthreads_online_cpu() paths, return -ENOMEM without
> > a warning.  kthread_affine_node() returns void, so it cannot report the
> > error either, and it only skips the affinity setup for this thread.  Return
> > early without warning, matching those callers.

Unfortunately there is no way to handle that correctly. It's the thread main
function and making it return early without executing the associated callback
doesn't sound like a better idea over what we do now.

A warning is the only way at this stage to tell that the affinity of the kthread
will be mishandled.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs