[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ak36qadrkrplficbyceqx4cadgokxwolyyu3slgq4ag2kfjif5@7bxxiipqgdam>
Date: Sat, 10 May 2025 10:59:27 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org, x86@...nel.org,
Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>
Subject: 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 <rostedt@...dmis.org> wrote:
> >
> > From: Josh Poimboeuf <jpoimboe@...nel.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@...nel.org>
> > Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.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
Powered by blists - more mailing lists