| Message ID | 20220403160718.13730-1-9erthalion6@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Priorities for bpf progs attached to the same tracepoint | expand |
On Sun, Apr 3, 2022 at 9:08 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote: > > With growing number of various products and tools using BPF it could > easily happen that multiple BPF programs from different processes will > be attached to the same tracepoint. It seems that in such case there is > no way to specify a custom order in which those programs may want to be > executed -- it will depend on the order in which they were attached. > > Consider an example when the BPF program A is attached to tracepoint T, > the BFP program B needs to be attached to the T as well and start > before/end after the A (e.g. to monitor the whole process of A + > tracepoint in some way). If the program A could not be changed and is > attached before B, the order specified above will not be possible. > > One way to address this in a limited, but less invasive way is to > utilize link options structure to pass the desired priority to > perf_event_set_bpf_prog, and add new bpf_prog into the bpf_prog_array > based on its value. This will allow to specify the priority value via > bpf_tracepoint_opts when attaching a new prog. > > Does this make sense? There maybe a better way to achieve this, I would > be glad to hear any feedback on it. Not really. What's the real use case where you need to define relative order of BPF programs on the same kprobe or tracepoint. Each of them is supposed to be independent of each other and not depend on any order of their execution. Further, given such tracing programs are read-only relative to the kernel (they can't change kernel behavior), the order is supposed to be irrelevant. > > Dmitrii Dolgov (2): > bpf: tracing: Introduce prio field for bpf_prog > libbpf: Allow setting bpf_prog priority > > drivers/media/rc/bpf-lirc.c | 4 ++-- > include/linux/bpf.h | 3 ++- > include/linux/trace_events.h | 7 ++++--- > include/uapi/linux/bpf.h | 1 + > kernel/bpf/core.c | 19 +++++++++++++++++-- > kernel/bpf/syscall.c | 3 ++- > kernel/events/core.c | 8 ++++---- > kernel/trace/bpf_trace.c | 8 +++++--- > tools/include/uapi/linux/bpf.h | 1 + > tools/lib/bpf/bpf.c | 1 + > tools/lib/bpf/bpf.h | 1 + > tools/lib/bpf/libbpf.c | 4 +++- > tools/lib/bpf/libbpf.h | 6 ++++-- > 13 files changed, 47 insertions(+), 19 deletions(-) > > -- > 2.32.0 >
> On Sun, Apr 03, 2022 at 05:17:46PM -0700, Andrii Nakryiko wrote: > On Sun, Apr 3, 2022 at 9:08 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote: > > > > With growing number of various products and tools using BPF it could > > easily happen that multiple BPF programs from different processes will > > be attached to the same tracepoint. It seems that in such case there is > > no way to specify a custom order in which those programs may want to be > > executed -- it will depend on the order in which they were attached. > > > > Consider an example when the BPF program A is attached to tracepoint T, > > the BFP program B needs to be attached to the T as well and start > > before/end after the A (e.g. to monitor the whole process of A + > > tracepoint in some way). If the program A could not be changed and is > > attached before B, the order specified above will not be possible. > > > > One way to address this in a limited, but less invasive way is to > > utilize link options structure to pass the desired priority to > > perf_event_set_bpf_prog, and add new bpf_prog into the bpf_prog_array > > based on its value. This will allow to specify the priority value via > > bpf_tracepoint_opts when attaching a new prog. > > > > Does this make sense? There maybe a better way to achieve this, I would > > be glad to hear any feedback on it. > > Not really. What's the real use case where you need to define relative > order of BPF programs on the same kprobe or tracepoint. Each of them > is supposed to be independent of each other and not depend on any > order of their execution. Further, given such tracing programs are > read-only relative to the kernel (they can't change kernel behavior), > the order is supposed to be irrelevant. The immediate trigger for this idea was inconvenience we faced, trying to instrument one bpf prog with another. I guess the best practice in such case would be to attach to fentry/fexit of the target bpf prog, but from what I understand in this case there is no way to get information about tracepoint arguments the target prog has received. Stepping back a bit, what would be the best way of handling this?
On Mon, Apr 04, 2022 at 05:29:53PM +0200, Dmitry Dolgov wrote: > > On Sun, Apr 03, 2022 at 05:17:46PM -0700, Andrii Nakryiko wrote: > > On Sun, Apr 3, 2022 at 9:08 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote: > > > > > > With growing number of various products and tools using BPF it could > > > easily happen that multiple BPF programs from different processes will > > > be attached to the same tracepoint. It seems that in such case there is > > > no way to specify a custom order in which those programs may want to be > > > executed -- it will depend on the order in which they were attached. > > > > > > Consider an example when the BPF program A is attached to tracepoint T, > > > the BFP program B needs to be attached to the T as well and start > > > before/end after the A (e.g. to monitor the whole process of A + > > > tracepoint in some way). If the program A could not be changed and is > > > attached before B, the order specified above will not be possible. > > > > > > One way to address this in a limited, but less invasive way is to > > > utilize link options structure to pass the desired priority to > > > perf_event_set_bpf_prog, and add new bpf_prog into the bpf_prog_array > > > based on its value. This will allow to specify the priority value via > > > bpf_tracepoint_opts when attaching a new prog. > > > > > > Does this make sense? There maybe a better way to achieve this, I would > > > be glad to hear any feedback on it. > > > > Not really. What's the real use case where you need to define relative > > order of BPF programs on the same kprobe or tracepoint. Each of them > > is supposed to be independent of each other and not depend on any > > order of their execution. Further, given such tracing programs are > > read-only relative to the kernel (they can't change kernel behavior), > > the order is supposed to be irrelevant. > > The immediate trigger for this idea was inconvenience we faced, trying > to instrument one bpf prog with another. I guess the best practice in > such case would be to attach to fentry/fexit of the target bpf prog, yes. that's a recommended way. > but > from what I understand in this case there is no way to get information > about tracepoint arguments the target prog has received. Not quite. fentry/fexit have access to the arguments of instrumented bpf prog. See fexit_bpf2bpf.c In case of tracepoint the fentry prog will see the same 'ctx' pointer as bpf prog attached to a tp.
> On Tue, Apr 05, 2022 at 10:20:17AM -0700, Alexei Starovoitov wrote: > > The immediate trigger for this idea was inconvenience we faced, trying > > to instrument one bpf prog with another. I guess the best practice in > > such case would be to attach to fentry/fexit of the target bpf prog, > > yes. that's a recommended way. > > > but > > from what I understand in this case there is no way to get information > > about tracepoint arguments the target prog has received. > > Not quite. fentry/fexit have access to the arguments of instrumented bpf prog. > See fexit_bpf2bpf.c > In case of tracepoint the fentry prog will see the same 'ctx' pointer as > bpf prog attached to a tp. Thanks for the clarification, I'll take a look at it.