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

[Zi Yan <ziy@nvidia.com>]

On 17 Aug 2026, at 10:34, Zi Yan wrote:

> On 17 Aug 2026, at 9:55, Alan Stern wrote:
>
>> 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@nvidia.com> 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.
>
> Right. That is why I said “unless you have panic_on_oom set”. So panic_on_warn
> will not crash the kernel if user asks for more memory than what is available.
>
>>
>>> 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.
>
> But the warning here is when kernel user wants buddy allocator to give
> what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning
> tells that kernel user please ask for a reasonably sized memory.
>
>>
>>> 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.
>
> The issue here is that the inode.c code passes the user input len without
> checking to page allocator code. Capping that is a minimal requirement
> to prevent untrusted userspace input getting into trusted kernel space code
> easily.
>
>>
>>>> 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.
>
> In this case, the WARN is emitted not because of an allocation failure,
> but an invalid input to buddy allocator (order > MAX_PAGE_ORDER). The
> WARN is for kernel developers, telling them their code is asking too much
> free memory and core MM cannot handle it. Suppressing that means
> code outside MM can abuse page allocator. Code like doing
> alloc_pages(MAX_PAGE_ORDER + 1, __GFP_NOFAIL | __GFP_NOWARN) should not
> exist, instead of just getting pr_warn() and failures.

+other page allocator people

In case I am wrong.

Best Regards,
Yan, Zi