On Tue, Dec 17, 2024 at 2:46 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Dec 12, 2024 at 6:17 AM Menglong Dong <menglong8.dong@xxxxxxxxx> wrote: > > > > Hello, Alexei. > > > > After the series of "bpf: make tracing program support multi-link", I'm > > keeping think about the method to make tracing support multi-link. > > The previous discuss is here: > > > > https://lore.kernel.org/netdev/20240311093526.1010158-1-dongmenglong.8@xxxxxxxxxxxxx/ > > > > Now, I have a idea. How about we introduce a "function meta", which > > will reserve some space (such as 16-bytes) before function, just like > > what fentry do, except that the space we reserve for fentry is after the > > function. For example, we have a function "do_test", the layout is just > > like this: > > > > -------------> 16-bytes > > -------------> do_test > > -------------> __fentry__(nop) > > > > (Of curse, this need the suuport of the compiler, which is not available > > for now.) > > > > Then, we create a global trampoline for BPF. When we need to attach > > a BPF program to the function do_test(), we can allocate a > > "progs" of type struct tracing_progs, which is defined like this: > > > > struct tracing_progs { > > struct bpf_prog *fentry_progs; > > int fentry_count; > > struct bpf_prog *fexit_progs; > > int fexit_count; > > struct bpf_prog *fret_progs; > > int fret_count; > > }; > > > > Then, we store the address of the bpf program to "progs", and > > store the "progs" to "do_test - 8". And we make the __fentry__ > > of do_test() a call to the global bpf trampoline. > > > > In the global bpf trampoline, we can get the "progs" by "ip - 8", > > and call the bpf progs in it. > > > > The function meta can be used in more general way. For example, > > ftrace can alse use it. Then, we don't need to lookup the filter hash > > table. > > > > (Hope I'm disturbing you) > > Not at all. Sorry for the delay. > It's best to email the mailing list all the time. > Plenty of eyes there that can help evaluate and refine the idea. > > Overall, I think, it makes sense and there is a compiler > support already. > See -fpatchable-function-entry. Awesome! This makes it possible for me to implement such idea in the kernel right now~ > > But it's probably a hard sell to unconditionally add 8 or 16 bytes > to all functions in the kernel for x86, > though arm64 is already using -fpatchable-function-entry=4,2 > to support jumping to full 64-bit offsets (if I recall correctly). > > If it's only 8 extra bytes for x86 in front of the function > then please measure vmlinux text before/after. > Then we can decide. Okay, I'm testing on this pointer, and I'll send the result out to the list after I finish it. > Let's discuss this on the list. Thanks for the replying :/ Menglong Dong
