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

From: Dave Hansen

Date: Mon Jun 29 2026 - 12:08:28 EST


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?