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

[Quchaosheng]

Hi Bradley,

Thanks for the review.

On the AI question, since you asked directly: yes. I used an AI coding
assistant while preparing this, including the comment and the changelog. I
reviewed the change and tested it myself, but per
Documentation/process/coding-assistants.rst the submission should have carried
an "Assisted-by: LLM ..." tag and it did not. That is my mistake and I will add
the tag on any future revision.

On the NAK itself, I would like to answer your "what effect does this make
(except from the message)" question, because there is more to it than the text.

WARN_ON_ONCE(1) is not only a message. __warn() taints the kernel with
TAINT_WARN, prints modules and dumps the stack, and calls
check_panic_on_warn() (kernel/panic.c). So on any kernel running with
panic_on_warn=1, a failed GFP_KERNEL allocation in the thread creation path
becomes a full panic. That is the harm: the allocation failure is recoverable,
but the WARN reports it as a kernel bug, taints the box and can take it down.
pr_warn_once() keeps the report and drops the taint and the panic.

You also wrote on 14 September:

    Perhaps you could warn -> info? Because people may prefer to know if it's
    broken.

which I read as the same direction. I kept pr_warn_once() rather than
pr_info() so the line still stands out in the log.

On "under memory pressure you get what you get" and "fault injection is just a
test": I agree with both. Nothing is going to work well at that point. My only
argument for changing the severity is the taint/panic consequence above, not
the message length.

You said on 14 September that you were not comfortable taking a position until
the maintainers had input. Frederic wrote this code and has already commented
on the thread, so I am happy to leave the call to him.

Thanks,
Quchaosheng