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

On 17 Aug 2026, at 11:06, Alan Stern wrote:

> On Mon, Aug 17, 2026 at 10:37:29AM -0400, Zi Yan wrote:
>> On 17 Aug 2026, at 10:34, Zi Yan wrote:
>>> 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.
>
> That's fine, but it doesn't have to be done in a way that will crash
> many systems.
>
>>> 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.
>
> I disagree.  If the memory allocators are so fragile that userspace can
> break into the kernel just by asking for too much memory, the allocators
> should be fixed.
>
> Furthermore, it's generally recognized that library routines such as
> kmalloc() should check their own inputs rather than relying on their
> callers to do this work for them.
>
>>>>> 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.
>
> Again, I disagree with some of the details of this argument in this
> context.  For instance, if all kernel developers are supposed to know
> that they shouldn't ask kmalloc() for more than MAX_PAGE_ORDER at the
> risk of provoking a WARN, if this is such an important restriction, then
> shouldn't this requirement be mentioned in the kerneldoc for kmalloc()?


kmalloc is the normal method of allocating memory
for objects smaller than page size in the kernel.

See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/slab.h?h=v7.2#n1001

In this case, kmalloc is used to request > 4MB memory.

>
> Regardless, if it is important to let kernel developers know that their
> code is doing something wrong, why not make the WARN conditional on
> CONFIG_EXPERT or something similar?  In other words, prevent it from
> crashing production systems.



Best Regards,
Yan, Zi