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

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()?

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.

Alan Stern