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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 6/29/26 18:02, Dave Hansen 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.

But it wouldn't tell you what was the large stack? Or we could try to print
it inaccurately, and hope the non-overwritten deep part gives us enough insight?

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