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

Andrew Morton <akpm-de/[email protected]>
Newsgroups gmane.linux.usb.general,gmane.linux.kernel,gmane.linux.kernel.mm
Message-ID <[email protected]>
On Sun, 16 Aug 2026 21:47:58 -0400 "Zi Yan" <[email protected]> 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.

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.

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

> 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?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.