On Fri, May 09, 2025 at 02:53:38PM -0700, Andrii Nakryiko wrote: > On Fri, May 9, 2025 at 9:52 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > From: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > Signed-off-by: Steven Rostedt (Google) <rostedt@xxxxxxxxxxx> > > --- > > 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
