| Message ID | 20211004094857.30868-1-hotforest@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add support for writable bare tracepoint | expand |
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
Hello: This series was applied to bpf/bpf-next.git (master) by Andrii Nakryiko <andrii@kernel.org>: On Mon, 4 Oct 2021 17:48:54 +0800 you wrote: > From: Hou Tao <houtao1@huawei.com> > > Hi, > > The patchset series supports writable context for bare tracepoint. > > 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. > > [...] Here is the summary with links: - [bpf-next,v5,1/3] bpf: support writable context for bare tracepoint https://git.kernel.org/bpf/bpf-next/c/65223741ae1b - [bpf-next,v5,2/3] libbpf: support detecting and attaching of writable tracepoint program https://git.kernel.org/bpf/bpf-next/c/ccaf12d6215a - [bpf-next,v5,3/3] bpf/selftests: add test for writable bare tracepoint https://git.kernel.org/bpf/bpf-next/c/fa7f17d066bd You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Hi Steven, On 10/4/2021 10:46 PM, Steven Rostedt wrote: > 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? Not tried yet, but considering that VFS maintainer refused to have tracepoint in VFS layer, I'm not sure it is worth trying. > > 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: Or in a opposite way can eprobe add support for bare tracepoint ? > > 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 > .
On Sat, 9 Oct 2021 20:07:10 +0800 Hou Tao <houtao1@huawei.com> wrote: > Not tried yet, but considering that VFS maintainer refused to have tracepoint in > VFS layer, I'm not sure it is worth trying. The reason they refuse to is because it shows data that can become an API. But if that data is just a pointer, then it's not possible to become an API no more than a RAW tracepoint that BPF can hook to. Try asking. > > > > 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: > Or in a opposite way can eprobe add support for bare tracepoint ? If there's a way to expose the parameters of a bare tracepoint, then it should not be difficult to do so. Heck, we can just have "bare tracepoints" be events, that do nothing but repeat their pointer parameters, as that's basically all they do anyway. There's nothing fundamentally different between a "bare tracepoint" and a trace event that just defines the fields as the same as the parameters to a tracepoint, except now you have another way to know what the parameters are. -- Steve
From: Hou Tao <houtao1@huawei.com> Hi, The patchset series supports writable context for bare tracepoint. 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. Comments are always welcome. [1]: https://lore.kernel.org/lkml/20190426184951.21812-1-mmullins@fb.com Change log: v5: * rebased on bpf-next * patch 1: add Acked-by tag * patch 2: handle invalid section name, make prefixes array being const v4: https://www.spinics.net/lists/bpf/msg47021.html * rebased on bpf-next * update patch 2 to add support for writable raw tracepoint attachment in attach_raw_tp(). * update patch 3 to add Acked-by tag v3: https://www.spinics.net/lists/bpf/msg46824.html * use raw_tp.w instead of raw_tp_writable as section name of writable tp * use ASSERT_XXX() instead of CHECK() * define a common macro for "/sys/kernel/bpf_testmod" v2: https://www.spinics.net/lists/bpf/msg46356.html * rebase on bpf-next tree * address comments from Yonghong Song * rename bpf_testmode_test_writable_ctx::ret as early_ret to reflect its purpose better. v1: https://www.spinics.net/lists/bpf/msg46221.html Hou Tao (3): bpf: support writable context for bare tracepoint libbpf: support detecting and attaching of writable tracepoint program bpf/selftests: add test for writable bare tracepoint include/trace/bpf_probe.h | 19 +++++++--- tools/lib/bpf/libbpf.c | 26 +++++++++++--- .../bpf/bpf_testmod/bpf_testmod-events.h | 15 ++++++++ .../selftests/bpf/bpf_testmod/bpf_testmod.c | 10 ++++++ .../selftests/bpf/bpf_testmod/bpf_testmod.h | 5 +++ .../selftests/bpf/prog_tests/module_attach.c | 35 +++++++++++++++++++ .../selftests/bpf/progs/test_module_attach.c | 14 ++++++++ tools/testing/selftests/bpf/test_progs.c | 4 +-- tools/testing/selftests/bpf/test_progs.h | 2 ++ 9 files changed, 119 insertions(+), 11 deletions(-)