On Tue, Mar 3, 2020 at 1:50 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > This is the reason why I think the 'link' between the main program and > the replacement program is in the "wrong direction". Instead I want to > introduce a new attachment API that can be used instead of > bpf_raw_tracepoint_open() - something like: > > prog_fd = sys_bpf(BPF_PROG_LOAD, ...); // dispatcher > func_fd = sys_bpf(BPF_PROG_LOAD, ...); // replacement func > err = sys_bpf(BPF_PROG_REPLACE_FUNC, prog_fd, btf_id, func_fd); // does *not* return an fd > > When using this, the kernel will flip the direction of the reference > between BPF programs, so it goes main_prog -> replacement_prog. And > instead of getting an fd back, this will make the replacement prog share > its lifecycle with the main program, so that when the main program is > released, so is the replacement (absent other references, of course). > There could be an explicit 'release' command as well, of course, and a > way to list all replacements on a program. Nack to such api. We hit this opposite direction issue with xdp and tc in the past. Not going to repeat the same mistake again.
