Re: [PATCH v3 00/40] mm: make VMA flag semantics explicit, eliminate VM_SPECIAL

[Lorenzo Stoakes (ARM)]

On Sat, Sep 26, 2026 at 12:06:22AM +0200, Arnd Bergmann wrote:
> On Thu, Sep 17, 2026, at 18:22, Lorenzo Stoakes (ARM) wrote:
> >
> >  mm/vma.c                                   | 246 +++++++++++++++++++-------
>
> Hi Lorenzo,
>
> I see that in linux-next there is a new build failure in some
> configurations in code that you are changing here:

Thanks for the report!

>
> mm/vma.c: In function '__mmap_region':
> mm/vma.c:3083:1: error: the frame size of 1552 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>
> I don't immediately see anything that you did that would have introduced
> something bad that wasn't already there, so it's likely just gone from
> just below the limit I was using for my testing to just above. The 1536
> byte limit is what I use on 64-bit builds with KASAN and otherwise
> still has a clean build (with a small number of local fixup patches).

Hmm are you specifying this limit manually somehow?

>
> What I see is that this function has multiple structures on the
> stack that have nontrivial sizes:
>
>         VMA_ITERATOR(vmi, mm, addr); /* 104 bytes */
>         MMAP_STATE(map, mm, &vmi, addr, len,...); /* 384 bytes */
>         struct vm_area_desc desc; /* 128 bytes */
>
> The config that caused this is https://pastebin.com/raw/5M95qHy5,
> which is an x86-64 build with CONFIG_KASAN_STACK enabled, and likely
> a few other configuration options that made it a little worse.
> KASAN_STACK tends to double the stack size used by structures
> in order to catch out-of-bounds accesses.

Yeah, there is a lot on the stack admittedly but there is also a lot of state
being used. I'm sure we can reduce it.

>
> If I sprinkle some 'noinline_for_stack' annotations on functions
> called by __mmap_region(), I can get the size down to 1144 in this
> config, but that doesn't sound like a great workaround.
>
> The large stack usage is potentially harmful if this ends up
> in call chains that have additional large stack usage (e.g.
> kmalloc() leading to reclaim). Any ideas for how to reduce it here?

That can never happen :) this call chain is _only_ for an mmap() call.

>
>      Arnd

In general I am absolutely taking this seriously and will find a way to
reduce this, but my only question is whether this is actually something
that needs to be done in this series?

Because it's already huge and I would rather avoid adding yet another patch
to it if possible.

If I can do it as a follow-up that'd be ideal!

Thanks!

--
Cheers, Lorenzo