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
