> On Sat, Nov 25, 2023 at 12:46:57PM -0800, Song Liu wrote: > On Wed, Nov 22, 2023 at 11:22 AM Dmitrii Dolgov <9erthalion6@xxxxxxxxx> wrote: > > > > Currently, it's not allowed to attach an fentry/fexit prog to another > > one of the same type. At the same time it's not uncommon to see a > > tracing program with lots of logic in use, and the attachment limitation > > prevents usage of fentry/fexit for performance analysis (e.g. with > > "bpftool prog profile" command) in this case. An example could be > > falcosecurity libs project that uses tp_btf tracing programs. > > > > Following the corresponding discussion [1], the reason for that is to > > avoid tracing progs call cycles without introducing more complex > > solutions. Relax "no same type" requirement to "no progs that are > > already an attach target themselves" for the tracing type. In this way > > only a standalone tracing program (without any other progs attached to > > it) could be attached to another one, and no cycle could be formed. > > Actually, is it really possible to have tracing programs form a cycle? > AFAICT, attach_prog_fd is specified at BPF_PROG_LOAD. So a > program can never attach to another program loaded after it. Did I > miss something? Only BPF_PROG_TYPE_EXT program can change > target_fd at BPF_LINK_CREATE time. Yes, I've mentioned that in the v1 thread, it doesn't look like the actual tracing program cycle is possible currently (to test that a cycle would be prevented I had to minimally modify few other bits of prog lifecycle; although those changes were mostly in the verifier, I can check about attach_prog_fd). My understanding is that the original intent was to make everything robust against the future changes, even in case if the code around would make cycles possible at some point.