Re: [PATCH v2 2/2] kthread: Report cpumask allocation failure without warning

[Frederic Weisbecker]

Le Thu, Sep 17, 2026 at 05:21:16PM +0800, Quchaosheng a écrit :
> 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.

panic_on_warn=1 can be useful for debugging but I doubt it's ever a good
idea on production though.

> 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:

Well I'm not exactly a kthread maintainer, though we all care about that file
and I can do a pull request when necessary, so I'm just giving my opinion here:
I would rather keep the warning because when that allocation fails, something
bad happens that is unrecoverable and that's what warnings are for.

> 
> 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.

I don't think it's a necessary change but let's see if others have different
opinions.

> 
> 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.

Ah yes please! It's useful for us to know that when we review.

> Sorry for the extra round trip.

No problem, iterations is how we work :-)

Thanks.

-- 
Frederic Weisbecker
SUSE Labs