On Thu, Apr 02, 2020 at 02:24:33PM -0700, Andrey Ignatov wrote: > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> [Thu, 2020-04-02 13:22 -0700]: > > On Fri, Mar 27, 2020 at 12:11:15PM +0100, Toke Høiland-Jørgensen wrote: > > > > > > Current code is in [0], for those following along. There are two bits of > > > kernel support missing before I can get it to where I want it for an > > > initial "release": Atomic replace of the dispatcher (this series), and > > > the ability to attach an freplace program to more than one "parent". > > > I'll try to get an RFC out for the latter during the merge window, but > > > I'll probably need some help in figuring out how to make it safe from > > > the verifier PoV. > > > > I have some thoughts on the second part "ability to attach an freplace > > to more than one 'parent'". > > I think the solution should be more generic than just freplace. > > fentry/fexit need to have the same feature. > > Few folks already said that they want to attach fentry to multiple > > kernel functions. It's similar to what people do with kprobe progs now. > > (attach to multiple and differentiate attach point based on parent IP) > > Similarly "bpftool profile" needs it to avoid creating new pair of fentry/fexit > > progs for every target bpf prog it's collecting stats about. > > I didn't add this ability to fentry/fexit/freplace only to simplify > > initial implementation ;) I think the time had come. > > Currently fentry/fexit/freplace progs have single prog->aux->linked_prog pointer. > > It just needs to become a linked list. > > The api extension could be like this: > > bpf_raw_tp_open(prog_fd, attach_prog_fd, attach_btf_id); > > (currently it's just bpf_raw_tp_open(prog_fd)) > > The same pair of (attach_prog_fd, attach_btf_id) is already passed into prog_load > > to hold the linked_prog and its corresponding btf_id. > > I'm proposing to extend raw_tp_open with this pair as well to > > attach existing fentry/fexit/freplace prog to another target. > > Internally the kernel verify that btf of current linked_prog > > exactly matches to btf of another requested linked_prog and > > if they match it will attach the same prog to two target programs (in case of freplace) > > or two kernel functions (in case of fentry/fexit). > > > > Toke, Andrey, > > if above kinda makes sense from high level description > > I can prototype it quickly and then we can discuss details > > in the patches ? > > Or we can drill further into details and discuss corner cases. > > That makes sense to me. > > I've also been thinking of a way to "transition" ext prog from one > target program to another, but I had an impression that limiting number > of target progs to one for an ext prog is "by design" and hard to > change, and was looking at introducing a way to duplicate existing ext > prog by its fd but with different attach_prog_fd and attach_btf_id (smth > like BPF_PROG_DUP command) instead. I think cloning the whole program is useful. iirc cilium folks wanted an ability for clone to have a different 'flavor' of the program. Like re-verifying and re-optimizing with new dead code elimination when global data changed. Like loading a prog to manage traffic for one k8 container with given IP, then cloning this prog for a different container with different IP. So clone is effectively a fast load where the verifier potentially doesn't need to do full verification of all paths. I think it's still a useful feature, but for this case, I hope, much simpler approach would do.
