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

["Arnd Bergmann" <arnd@arndb.de>]

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:

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).

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.

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?

     Arnd