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

[Lorenzo Stoakes (ARM)]

On Sat, Sep 26, 2026 at 03:06:33PM +0200, Arnd Bergmann wrote:
> On Sat, Sep 26, 2026, at 11:40, Lorenzo Stoakes (ARM) wrote:
> > On Sat, Sep 26, 2026 at 12:06:22AM +0200, Arnd Bergmann wrote:
> >>
> >> 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?
>
> It's a Kconfig setting upstream, but the way I'm doing it is to have
> patch that calculates a sensible default based on other options that
> is a little smaller than the default (currently 2048 bytes) on x86-64
> to catch more cases where something sticks out.

I see.

So this is an early warning more or less :)

>
> >> 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.
>
> I mean more functions called /from/ here, something like
>
>   __mmap_region()
>   __mmap_new_vma()
>   vm_area_alloc()
>   kmem_cache_alloc(..., GFP_KERNEL)
>   slab_alloc_node()
>   allocate_slab()
>   alloc_slab_page()
>   __alloc_pages_slowpath()
>   __alloc_pages_direct_reclaim()
>   __perform_reclaim()
>   try_to_free_pages()
>   shrink_zones()
>   shrink_node()
>   lru_gen_shrink_node()
>   shrink_many()
>   shrink_one()
>   try_to_shrink_lruvec()
>   evict_folios()
>   shrink_folio_list()
>   pageout()
>   shmem_writeout()
>   swap_writeout()
>   swap_add_folio()
>   swap_write_submit()
>   nfs_swap_submit_write()
>   nfs_file_direct_write()
>   nfs_direct_extract_pages()
>   nfs_do_recoalesce()
>   __nfs_pageio_add_request()
>   nfs_pageio_doio()
>   pnfs_generic_pg_writepages()
>   pnfs_do_write()
>   pnfs_try_to_write_data()
>   filelayout_write_pagelist()
>   nfs_initiate_pgio()
>   nfs_local_doio()
>   nfs_local_do_write()
>   nfs_local_call_write()
>   ->write_iter()
>   generic_file_write_iter()
>   generic_write_sync()
>   vfs_fsync_range()
>   ->fsync()
>   xfs_file_fsync()
>   file_write_and_wait_range()
>   filemap_fdatawrite_range()
>   filemap_writeback()
>   do_writepages()
>   ->writepages()
>   xfs_vm_writepages()
>   iomap_writepages()
>   iomap_writeback_folio()
>   iomap_writeback_range()
>   ->writeback_range()
>   xfs_zoned_writeback_range()
>   iomap_add_to_ioend()
>   ->writeback_submit()
>   xfs_zoned_writeback_submit()
>   xfs_zone_alloc_and_submit()
>   xfs_submit_zoned_bio()
>   submit_bio()
>   submit_bio_noacct()
>   submit_bio_noacct_nocheck()
>   __submit_bio_noacct()
>   __submit_bio()
>   blk_mq_submit_bio()
>   blk_mq_run_dispatch_ops()
>   blk_mq_try_issue_directly()
>   blk_mq_run_hw_queue()
>   blk_mq_sched_dispatch_requests()
>   blk_mq_do_dispatch_sched()
>   __blk_mq_do_dispatch_sched()
>   blk_mq_dispatch_rq_list()
>   ->queue_rq()
>   scsi_queue_rq()
>   scsi_dispatch_cmd()
>   ->queuecommand()
>   ata_scsi_queuecmd()
>   __ata_scsi_queuecmd()
>   ata_scsi_translate()
>   ata_scsi_qc_issue()
>   ata_qc_issue()
>   qc_issue()
>   ata_sff_qc_issue()
>   ata_sff_queue_pio_task()

Ugh delightful :)

>
> There are many ways the call chain can go of course, but the actual
> stack overflows do tend to follow this pattern where you are at a
> function with high stack usage and call kmalloc() during low memory
> condition and that ends up waiting for a block I/O down the line.
> (you normally don't go through swap and nfs, I was just looking
> for the worst case I could easily see in the code)

You certainly found quite the example haha.

>
> > 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!
>
> What I was hoping for is that as you are already deep into the
> exact code that caused the warning and you can already see something
> in there that may help.
>
> I don't think it's urgent, I just don't want it to be forgotten.

It won't be, it's now on my TODO and I see it as a relatively high priority
thing to follow up with.

Will likely send a patch for it next cycle (this is about the worst cycle I've
seen workload-size for mm so I don't really want to send anything more this time
around).

>
>      Arnd

--
Cheers, Lorenzo