On Sat, Sep 26, 2026, at 15:22, Lorenzo Stoakes (ARM) wrote:
> On Sat, Sep 26, 2026 at 03:06:33PM +0200, Arnd Bergmann wrote:
>>
>> 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.
>
> So this is an early warning more or less :)
Yes, a surprising number of these just point to stupid mistakes
where the developer had no they were adding a large object to
the stack. This instance here is unfortunately not an obvious
case.
>> 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.
I have previously toyed around with using VMALLOC_STACK on a reduced
stack size and syzcaller, so I knew roughly where the worst offenders
lie, but the list was from looking through the code just today.
>> > 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).
Sounds good, I'll keep the local hack to mark functions as noinline for the
moment then. Thanks,
Arnd
