Message-ID: <20200402220113.cqrh6hdjwt4ycvip@ast-mbp>
Date:   Thu, 2 Apr 2020 15:01:13 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrey Ignatov <rdna@...com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andriin@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: bpf: ability to attach freplace to multiple parents

On Thu, Apr 02, 2020 at 02:24:33PM -0700, Andrey Ignatov wrote:
> Alexei Starovoitov <alexei.starovoitov@...il.com> [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.

Powered by blists - more mailing lists