Re: [PATCH v2 00/13] Dynamic Kernel Stacks

[H. Peter Anvin]

On June 29, 2026 9:02:08 AM PDT, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>On 6/23/26 14:58, Thomas Gleixner wrote:
>> So as you already confirmed that the number of offenders is really low,
>> it'd be definitely a worthwhile effort to fix that for everyone and also
>> make the compiler people to get their act together 🙂
>
>One other thing comes to mind...
>
>We have debugging options for looking at max stack depth, like
>CONFIG_DEBUG_STACK_USAGE. But no distros seem to turn that on. There's
>also some ftrace stuff, but I assume none of that is used at runtime either.
>
>Do we need some max stack depth instrumentation that folks will actually
>turn on? It would be nice if we spat out warnings when folks went
>through 12k (or 8k) of stack so there was a chance of closing the loop
>and getting feedback from them.
>
>It could be done with really little overhead if the vmalloc()'d stacks
>set Accessed=0 on their PTEs and then checked them near vfree(). The
>PTEs are already getting touched there, so the cachelines should be hot
>anyway.
>
>The granularity would only be 4k, but it would be so cheap that we could
>turn it on universally. It would also be 100% deterministic.
>
>There are, of course, more games that could be played with stack depth
>checks on normal interrupts or NMIs. But those would be less deterministic.
>
>Thoughts?

Having a cheap stack depth check warning would seem to be a good thing.