Re: [PATCH v8 15/18] perf: Have get_perf_callchain() return NULL if crosstask and user are set

On Fri, May 09, 2025 at 02:53:38PM -0700, Andrii Nakryiko wrote:

On Fri, May 9, 2025 at 9:52 AM Steven Rostedt [off-list ref] wrote:

quoted

From: Josh Poimboeuf <jpoimboe@kernel.org>

get_perf_callchain() doesn't support cross-task unwinding for user space
stacks, have it return NULL if both the crosstask and user arguments are
set.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
 kernel/events/callchain.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index b0f5bd228cd8..abf258913ab6 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c

@@ -224,6 +224,10 @@ get_perf_callchain(struct pt_regs *regs, bool kernel, bool user,
        struct perf_callchain_entry_ctx ctx;
        int rctx, start_entry_idx;

+       /* crosstask is not supported for user stacks */
+       if (crosstask && user)
+               return NULL;

I think get_perf_callchain() supports requesting both user and kernel
stack traces, and if it's crosstask, you can still get kernel (but not
user) stack, if I'm reading the code correctly.

So by just returning NULL early you will change this behavior, no?

Yeah, that does seem like a bug.

Though crosstask in general is dubious, even for kernel stacks.

If the task is running while you're unwinding it, hilarity ensues.
There are guardrails in place, so it should be safe, it may just produce
nonsense.  But maybe the callers don't need perfection.

But also, it would seem to be a bad idea to allow one task to spy on
what another task's kernelspace is doing.  Does unpriv BPF allow that?

Though it seems even 'cat /proc/self/stack' is a privileged operation
these days, does unpriv BPF allow that as well?

-- 
Josh