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?