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

[David Laight <david.laight.linux@gmail.com>]

On Mon, 29 Jun 2026 10:29:53 -0700
"Zach O'Keefe" <zokeefe@google.com> wrote:

> Thanks All.
> 
> Yes, we run with CONFIG_DEBUG_STACK_USAGE -- which allows us to put
> together information on max stack depth usage per host/task.
> 
> I'd like to create an upstream recipe for finding deep stacks
> statically by combining per-frame sizes from --fstack-usage with
> callgraphs generated using Dan Carpenter's smatch utility. In
> particular, smatch's selling point is the ability to track indirect
> calls (i.e., calls through vm_operations, super_operations, etc).
> While easy to set up, and working well out-of-the-box, this currently
> results in many false-positive callstack possibilities, so I'm trying
> to pare down the graph to get to some useable data. Additionally will
> need to know what exception-originating stacks can possibly be
> superimposed on the base callstack, for the given configuration -- for
> example, today, only a few places we'd expect to see #PF stack.
> Lastly, I've been analyzing perf-like data to authoritatively
> construct the call graphs as well -- or at least to use for
> seeding/filtering the static call graph.

I've thought of trying to do that getting objtool to output the
stack offset of every call (I think it ends up in the debug info)
and using the IBT function hashes to group indirect calls together.
But I've not got further than failing to compile a kernel with the
required compiler options :-(

Unravelling the mess and breaking recursive call loops is a separate
problem - which you seem to have hit.
(I've done it many, many years ago for an embedded system with no
indirect calls of recursion.)

I think objtool already works out a lot of things you'd need.
Getting it to output a file of:
	'func_x at stack offset off calls func_y'
would give something to post-process.

	David



> 
> Thanks,
> Zach
>