Re: [syzbot] [mm?] WARNING in v9fs_fid_get_acl (2)

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 22 Sep 2026 17:45:14 +0900 Dominique Martinet <asmadeus@codewreck.org> wrote:

> (+Nguyen in Cc as he tried resending sloppy patches after this)
> 
> Andrew Morton wrote on Sat, Sep 19, 2026 at 03:14:51AM -0700:
> > > WARNING: mm/page_alloc.c:5340 at alloc_order_allowed mm/page_alloc.c:5340 [inline], CPU#0: syz.1.357/7872
> > > WARNING: mm/page_alloc.c:5340 at __alloc_frozen_pages_noprof+0x2137/0x3300 mm/page_alloc.c:5397, CPU#0: syz.1.357/7872
> > 
> > Thanks.  Caused by an old v9fs bug.  A fix was proposed but never merged:
> > https://lists.openwall.net/linux-kernel/2024/02/02/806?utm_source=chatgpt.com
> 
> Right, we've been going in circle with this since forever, and nobody
> answered Christian Schoenebeck's question[1] about what the limit should
> be, and while I don't care much ultimately I sort of agree with him
> (e.g. limit should be XATTR_SIZE_MAX for anything that the VFS layer
> touches, but acl are converted within the 9p subsystem and could be
> arbitrarily large so status quo of a KMALLOC_MAX_SIZE limit because they
> could come from something else)
> 
> Andrew, if you have an opinion on whether we should cap the acl sizes
> anyway, please say...

whome.  Well, if the converted ACLs can be large and it's hard to
figure out how large then yes, some pre-canned limit is difficult.  So
it's OK to leave the decision up to kmalloc() and just put a (nicely
commented!) __GFP_NOWARN in there.

otoh, if we're permitting workloads to trigger a large number of large
allocations then that might be a problem from a utilization or even DoS
point of view.