Re: [PATCH v2 2/2] kthread: Report cpumask allocation failure without warning
From: Quchaosheng
Date: Thu Sep 17 2026 - 05:39:16 EST
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