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@xxxxxxxxx> 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.
