Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > 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. Care to elaborate? What mistake, and what was the issue? -Toke
