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

[Dave Hansen]

On 6/29/26 13:17, Matthew Wilcox wrote:
> On Mon, Jun 29, 2026 at 09:02:08AM -0700, Dave Hansen wrote:
>> 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.
> I mean, if we just memset64() the whole stack to 0x535441434b544f50 and
> then searched the stack for the lowest word that wasn't that value at
> process exit, we'd get a much more granular idea with vanishingly few
> false positives.

What I was going for was some first pass check that would be so
ridiculously cheap that it could be turned on everywhere. Those 4 PTEs
are going to be touched in the exit code path anyway, so there's not
even any additional cache impact.

But, yeah, if it needed to be more more fine-grained than pages, what
you describe could 100% be done. But, at the cost of pulling in more
cachelines. It's similar to what Vlastimil was pointing out: there's a
lot of good info in the bottom of the stack long after it was popped.
There is fine-graned usage data and probably some stack frame remnants
that could point the finger at what code is to blame.