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
