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

[Alan Stern]

On Tue, Aug 18, 2026 at 07:45:31PM -0400, Zi Yan wrote:
> On Mon Aug 17, 2026 at 11:12 PM EDT, Alan Stern wrote:
> > 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.

That's exactly why the WARN should remain enabled in testing/development 
kernels.  Just not in production kernels.

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

Certainly.  But the mm subsystem can't tell which of these is the case; 
it _has_ to leave the decision of how to handle the failure up to the 
caller.

Alan Stern