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

[Alan Stern]

On Sun, Aug 16, 2026 at 07:42:13PM -0700, Andrew Morton wrote:
> On Sun, 16 Aug 2026 21:47:58 -0400 "Zi Yan" <ziy@xxxxxxxxxx> wrote:
> 
> > >
> > >> > I prefer Andrew's first suggestion.  If the user asks the kernel to copy 
> > >> > too much data, just fail -- with no warning.
> > >> 
> > >> __GFP_WARN gets rid of all other warnings, even if user asks for a
> > >> reasonable size. Why use such a big hammer?
> > >
> > > Because on many systems, WARN causes the kernel to crash.  You don't 
> > > want the entire system to crash just because the user asked for more 
> > > memory than was available.
> > 
> > User asking for more memory that what is available is pretty common and
> > should not trigger a WARN or crash, unless you have panic_on_oom set.
> 
> I assume Alan is referring to panic_on_warn.

Yes.

> Heaven knows how common panic_on_warn usage is.  Gemini tells me "There
> is no exact global headcount or precise user metric for how many people
> use panic_on_warn.  However, the setting is widely enabled across a few
> billion Android devices and many cloud/server provider host kernels
> where automated failover makes a full reboot preferable to running with
> an unknown warning state".
> 
> So I do think that WARNs are more serious than we (mm developers) tend
> to assume.

I do know that Greg KH has pretty strong feelings about this issue.

> So we just shouldn't permit userspace to trivially trigger a
> page-allocation WARN.  Especially if the caller is perfectly capable of
> handling an ENOMEM allocation failure, as appears to be the case with
> usb-gadget.
> 
> (Does usb-gadget actually get used by Android?  Surely not by cloud
> providers!)
> 
> (Can this WARN be triggered by unprivileged userspace?  I didn't look,
> this matters a lot).

I don't think it can.  Regardless, even privileged userspace shouldn't 
be able to crash the whole system by doing something that ought to 
return a harmless error.

> > You can mmap a virtual address range bigger than your physical memory
> > size plus your swap space and try to fault all pages in. That would
> > cause OOM and the system should not crash.
> 
> Right.  As long as it doesn't trigger a WARN!
> 
> 
> 
> 
> Perhaps we should revisit this.
> 
> Why are we emitting a WARN if an allocation fails, given that this will
> often panic the kernel?  Should we on the core MM side dial that back
> to a pr_warn() and a helpful backtrace?

I think that would be a very good idea.  Only the caller knows whether 
an allocation failure will leave the system in an unstable state; the 
library routine shouldn't try to make this decision on its own.

Alan Stern