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

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:

quoted

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.

quoted

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

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)

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.

     Arnd