[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250423145308.5f808ada@gandalf.local.home>
Date: Wed, 23 Apr 2025 14:53:08 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Linux Trace Kernel
<linux-trace-kernel@...r.kernel.org>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Masami Hiramatsu <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, David Ahern <dsahern@...nel.org>,
Juri Lelli <juri.lelli@...il.com>, Breno Leitao <leitao@...ian.org>,
netdev@...r.kernel.org, Alexei Starovoitov <alexei.starovoitov@...il.com>,
bpf@...r.kernel.org, Gabriele Monaco <gmonaco@...hat.com>
Subject: Re: [RFC][PATCH] tracepoint: Have tracepoints created with
DECLARE_TRACE() have _tp suffix
On Wed, 23 Apr 2025 11:21:25 -0700
Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> The part about accessing only from code within the kernel isn't true.
> Can we please drop that? BPF program can be attached to these bare
> tracepoints just fine without tracefs (so-called BPF raw tracepoint
> program types).
Is it possible to see a list of these tracepoints from user space? If not,
then it's only available via the kernel. Sure BPF and even trace probes can
attach to them. Just like attaching to functions. The point is, they are
not exposed directly to user space. User space only knows about it if the
user has access to the kernel.
Unless BPF does expose what's avaliable, does it?
>
> But I don't have an objection to the change itself, given all of them
> currently do have _tp suffix except a few that we have in BPF
> selftests's module, just as Jiri mentioned.
>
> Acked-by: Andrii Nakryiko <andrii@...nel.org>
Thanks,
-- Steve
Powered by blists - more mailing lists