From: Steven Rostedt <rostedt@goodmis.org>
To: Hou Tao <hotforest@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>, Yonghong Song <yhs@fb.com>,
Martin KaFai Lau <kafai@fb.com>, Ingo Molnar <mingo@redhat.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org, houtao1@huawei.com
Subject: Re: [PATCH bpf-next v5 0/3] add support for writable bare tracepoint
Date: Mon, 4 Oct 2021 10:46:29 -0400 [thread overview]
Message-ID: <20211004104629.668cadeb@gandalf.local.home> (raw)
In-Reply-To: <20211004094857.30868-1-hotforest@gmail.com>
On Mon, 4 Oct 2021 17:48:54 +0800
Hou Tao <hotforest@gmail.com> wrote:
> The main idea comes from patchset "writable contexts for bpf raw
> tracepoints" [1], but it only supports normal tracepoint with
> associated trace event under tracefs. Now we have one use case
> in which we add bare tracepoint in VFS layer, and update
> file::f_mode for specific files. The reason using bare tracepoint
> is that it doesn't form a ABI and we can change it freely. So
> add support for it in BPF.
Are the VFS maintainers against adding a trace event with just a pointer as
an interface?
That is, it only gives you a pointer to what is passed in, but does not
give you anything else to form any API against it.
This way, not only does BPF have access to this information, so do the
other tracers, through the new eprobe interface:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/trace?id=7491e2c442781a1860181adb5ab472a52075f393
(I just realized we are missing updates to the Documentation directory).
event probes allows one to attach to an existing trace event, and then
create a new trace event that can read through pointers. It uses the same
interface that kprobes has.
Just adding trace events to VFS that only have pointers would allow all of
BPF, perf and ftrace access as eprobes could then get the data you are
looking for.
-- Steve
next prev parent reply other threads:[~2021-10-04 14:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 9:48 [PATCH bpf-next v5 0/3] add support for writable bare tracepoint Hou Tao
2021-10-04 9:48 ` [PATCH bpf-next v5 1/3] bpf: support writable context for " Hou Tao
2021-10-04 9:48 ` [PATCH bpf-next v5 2/3] libbpf: support detecting and attaching of writable tracepoint program Hou Tao
2021-10-04 9:48 ` [PATCH bpf-next v5 3/3] bpf/selftests: add test for writable bare tracepoint Hou Tao
2021-10-04 14:46 ` Steven Rostedt [this message]
2021-10-09 12:07 ` [PATCH bpf-next v5 0/3] add support " Hou Tao
2021-10-11 14:34 ` Steven Rostedt
2021-10-08 20:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211004104629.668cadeb@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hotforest@gmail.com \
--cc=houtao1@huawei.com \
--cc=kafai@fb.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.