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