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

[Arnd Bergmann]

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.

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