From: Bradley Morgan <brads@mainlining.org>
To: quchaosheng000406@163.com
Cc: boqun@kernel.org, linux-kernel@vger.kernel.org,
longman@redhat.com, mingo@redhat.com, peterz@infradead.org,
will@kernel.org
Subject: Re: [PATCH 2/2] kthread: Drop warning on cpumask allocation failure in kthread_affine_node()
Date: Mon, 14 Sep 2026 17:52:35 +0100 [thread overview]
Message-ID: <F1E3C43A-E5F5-4D85-A59D-FECC35AE0C87@mainlining.org> (raw)
In-Reply-To: <20260914120941.63968-2-quchaosheng000406@163.com>
On 14 September 2026 13:09:41 BST, Quchaosheng <quchaosheng000406@163.com>
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
Interesting.
>
>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.
Makes sense.
>
>Reported-by: syzbot+37ca7ae3e98cb65c3209@syzkaller.appspotmail.com
>Closes: https://syzkaller.appspot.com/bug?extid=37ca7ae3e98cb65c3209
>Signed-off-by: Quchaosheng <quchaosheng000406@163.com>
>---
> kernel/kthread.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>diff --git a/kernel/kthread.c b/kernel/kthread.c
>index a3f95c904..f735a74b6 100644
>--- a/kernel/kthread.c
>+++ b/kernel/kthread.c
>@@ -355,10 +355,8 @@ static void kthread_affine_node(void)
> if (WARN_ON_ONCE(kthread_is_per_cpu(current)))
> return;
>
>- if (!zalloc_cpumask_var(&affinity, GFP_KERNEL)) {
>- WARN_ON_ONCE(1);
>+ if (!zalloc_cpumask_var(&affinity, GFP_KERNEL))
> return;
>- }
Uhh, I'm unsure about this.
The warn may be intended?
Perhaps you could warn -> info?
Because people may prefer to know if it's broken.
I'm not comfortable adding a tag until the maintainers have a input
>
> mutex_lock(&kthread_affinity_lock);
> WARN_ON_ONCE(!list_empty(&kthread->affinity_node));
>
>
>
--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/
next prev parent reply other threads:[~2026-09-14 16:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 12:09 Quchaosheng
2026-09-14 16:52 ` Bradley Morgan [this message]
2026-09-14 17:04 ` Waiman Long
2026-09-15 10:45 ` Frederic Weisbecker
2026-09-16 1:59 ` [PATCH] kthread: Report cpumask allocation failure without warning Quchaosheng
2026-09-16 16:40 ` Bradley Morgan
2026-09-17 5:15 ` Quchaosheng
2026-09-16 8:10 ` [PATCH 2/2] kthread: Drop warning on cpumask allocation failure in kthread_affine_node() Quchaosheng
-- strict thread matches above, loose matches on Subject: below --
2026-09-14 12:09 Quchaosheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F1E3C43A-E5F5-4D85-A59D-FECC35AE0C87@mainlining.org \
--to=brads@mainlining.org \
--cc=boqun@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=quchaosheng000406@163.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®