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

[David Laight]

On Mon, 29 Jun 2026 09:02:08 -0700
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.

For testing purposes you'd probably want to do the check in other places.
Possibly slow paths that might be called with a deep stack as well as
context switch and return to uses.
I guess you could copy the stack (to global data) so that it could be
dumped for diagnostics (finding the relevant stack trace is left as an
exercise to the reader).
Similarly it might be worth allocating an extra 4k page so that stack could
be offset so the warning happens at (say) 12k.

	David

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