Re: [PATCH bpf-next v1 06/19] bpf: support bpf tracing/iter programs for BPF_LINK_UPDATE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 28, 2020 at 10:04:54PM -0700, Yonghong Song wrote:
> 
> 
> On 4/28/20 6:32 PM, Martin KaFai Lau wrote:
> > On Mon, Apr 27, 2020 at 01:12:41PM -0700, Yonghong Song wrote:
> > > Added BPF_LINK_UPDATE support for tracing/iter programs.
> > > This way, a file based bpf iterator, which holds a reference
> > > to the link, can have its bpf program updated without
> > > creating new files.
> > > 

[ ... ]

> > > --- a/kernel/bpf/bpf_iter.c
> > > +++ b/kernel/bpf/bpf_iter.c

[ ... ]

> > > @@ -121,3 +125,28 @@ int bpf_iter_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
> > >   		kfree(link);
> > >   	return err;
> > >   }
> > > +
> > > +int bpf_iter_link_replace(struct bpf_link *link, struct bpf_prog *old_prog,
> > > +			  struct bpf_prog *new_prog)
> > > +{
> > > +	int ret = 0;
> > > +
> > > +	mutex_lock(&bpf_iter_mutex);
> > > +	if (old_prog && link->prog != old_prog) {
hmm....

If I read this function correctly,
old_prog could be NULL here and it is only needed during BPF_F_REPLACE
to ensure it is replacing a particular old_prog, no?


> > > +		ret = -EPERM;
> > > +		goto out_unlock;
> > > +	}
> > > +
> > > +	if (link->prog->type != new_prog->type ||
> > > +	    link->prog->expected_attach_type != new_prog->expected_attach_type ||
> > > +	    strcmp(link->prog->aux->attach_func_name, new_prog->aux->attach_func_name)) {
> > Can attach_btf_id be compared instead of strcmp()?
> 
> Yes, we can do it.
> 
> > 
> > > +		ret = -EINVAL;
> > > +		goto out_unlock;
> > > +	}
> > > +
> > > +	link->prog = new_prog;
> > Does the old link->prog need a bpf_prog_put()?
> 
> The old_prog is replaced in caller link_update (syscall.c):

> static int link_update(union bpf_attr *attr)
> {
>         struct bpf_prog *old_prog = NULL, *new_prog;
>         struct bpf_link *link;
>         u32 flags;
>         int ret;
> ...
>         if (link->ops == &bpf_iter_link_lops) {
>                 ret = bpf_iter_link_replace(link, old_prog, new_prog);
>                 goto out_put_progs;
>         }
>         ret = -EINVAL;
> 
> out_put_progs:
>         if (old_prog)
>                 bpf_prog_put(old_prog);
The old_prog in link_update() took a separate refcnt from bpf_prog_get().
I don't see how it is related to the existing refcnt held in the link->prog.

or I am missing something in BPF_F_REPLACE?  



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux