On Wed, Feb 21, 2024 at 11:02 AM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Tue, Feb 20, 2024 at 6:45 PM 梦龙董 dongmenglong.8@bytedance.com wrote:
On Wed, Feb 21, 2024 at 10:35 AM 梦龙董 dongmenglong.8@bytedance.com wrote:
Hello,
On Wed, Feb 21, 2024 at 9:24 AM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Mon, Feb 19, 2024 at 7:51 PM Menglong Dong dongmenglong.8@bytedance.com wrote:
For now, the BPF program of type BPF_PROG_TYPE_TRACING is not allowed to be attached to multiple hooks, and we have to create a BPF program for each kernel function, for which we want to trace, even through all the program have the same (or similar) logic. This can consume extra memory, and make the program loading slow if we have plenty of kernel function to trace.
Should this be combined with multi link ? (As was recently done for kprobe_multi and uprobe_multi). Loading fentry prog once and attaching it through many bpf_links to multiple places is a nice addition, but we should probably add a multi link right away too.
I was planning to implement the multi link for tracing after this series in another series. I can do it together with this series if you prefer.
Should I introduce the multi link for tracing first, then this series? (Furthermore, this series seems not necessary.)
What do you mean "not necessary" ? Don't you want to still check that bpf prog access only N args and BTF for these args matches across all attach points ?
No, I means that if we should keep the
"Loading fentry prog once and attaching it through many bpf_links to multiple places"
and only keep the multi link.
Both methods need to check the accessed args of the target.