Re: [PATCH v12 00/14] unwind_user: x86: Deferred unwinding infrastructure

[Mathieu Desnoyers]

On 2025-07-02 10:56, Kees Cook wrote:
> On Tue, Jul 01, 2025 at 07:26:19PM -0400, Steven Rostedt wrote:
> > On Tue, 1 Jul 2025 15:49:23 -0700 Kees Cook <kees@xxxxxxxxxx> wrote:
> > > Okay, I've read the cover letter and this wiki page, but I am dense: why
> > > does the _kernel_ want to do this? Shouldn't it only be userspace that
> > > cares about userspace unwinding? I don't use perf, ftrace, and ebpf
> > > enough to make this obvious to me, I guess. ;)
> > [...]
> > Anyway, yeah, it's something that has a ton of interest, as it's the way
> > for tools like perf to give nice graphs of where user space bottlenecks
> > exist.
>
> Right! Yeah, I know it's very wanted -- I wasn't saying "don't this in
> the kernel", but quite literally, "*I* am missing something about why
> this is so important." :) And thank you, now I see: the sampling-based
> profiling of userspace must happen via the kernel.

I should add that once we have this in place for perf sampling,
it enables the following additional use-cases:

- Sample stack traces from specific tracepoints, e.g. system call
  entry. This allows associating the kernel tracepoints with their
  userspace call chain (causality) without requiring tracing of
  userspace.

- Implement a system call that allows a userspace thread to use the
  kernel stack sampling facilities on itself rather than reimplement
  the stack walk and sframe registry handling + decoding on the
  userspace side.

For this last point, it's only relevant because the infrastructure
will already be in place for stack sampling from the kernel. So we'd
eliminate duplication by allowing its use from userspace as well.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com