Re: [syzbot] [mm?] WARNING in ep_write_iter

["Zi Yan" <ziy@nvidia.com>]

On Mon Aug 17, 2026 at 11:12 PM EDT, Alan Stern wrote:
> On Mon, Aug 17, 2026 at 02:45:19PM -0400, Zi Yan wrote:
>> On 17 Aug 2026, at 11:37, Alan Stern wrote:
>> >>> Regardless, if it is important to let kernel developers know that their
>> >>> code is doing something wrong, why not make the WARN conditional on
>> >>> CONFIG_EXPERT or something similar?  In other words, prevent it from
>> >>> crashing production systems.
>> >
>> > You didn't respond to this.
>> 
>> I do not get your argument here. Why does this WARN need to be conditional
>> on CONFIG_EXPERT? What makes it special? Or you mean you want all WARNs
>> to be conditional CONFIG_EXPERT?
>
> This may be a moot point now, but I'll answer the questions anyway.
>
> This WARN should be conditional on something indicating that the kernel 
> is meant for testing rather than production (not necessarily 
> CONFIG_EXPERT but something like it) because it does not indicate that 
> an operation has failed badly enough to leave the kernel in a 
> dangerously unstable state.  Rather, it indicates that a programmer has 
> tried to do something that can't possibly succeed.  The result should 
> not be dangerous because the caller should always check kmalloc()'s 
> return value.  If the caller is unable to recover from a memory 
> allocation failure then it is the caller's responsibility to WARN, not 
> kmalloc()'s.

I agree with you that this situation, kmalloc cannot satisfy the
too-large-to-allocate request, is not fatal and is recoverable since the
caller handles NULL result. But without the warning, some callers have
no way to know if they are sending an unexpected/undesirable request
that might come from a bug in their code. With the patch, kmalloc
returning NULL means two ambiguous things: 1. the request cannot be
satisfied due to current memory system condition, e.g., insufficient
free memory; 2. the request itself is unreasonable/unexpected. It could
make debugging harder.

>
> The same is true for all other WARN statements.  If they merely indicate 
> a programming infelicity and not a dangerous failure then they should 
> not fire in production kernels.

It is hard to tell whether a condition is dangerous or not. A caller
sending a too-large-to-allocate request can come from a miscalculation
or a wrong user input. It can also come from some data
corruption/overwrite, clobbering the request size itself.

-- 
Best Regards,
Yan, Zi