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
