Re: [PATCH bpf-next 2/9] samples: bpf: refactor hbm program with libbpf

On Wed, Nov 18, 2020 at 11:10 AM Martin KaFai Lau <[email protected]> wrote:
>
> On Tue, Nov 17, 2020 at 02:56:37PM +0000, Daniel T. Lee wrote:
> [ ... ]
>
> > +
> > +cleanup:
> > +     if (rc != 0)
> so this test can be avoided.
>

Thanks for pointing me out! I will follow this approach.

> > +             bpf_object__close(obj);
> > +
> > +     return rc;
> >  }
> >
> > [...]
> >       if (!outFlag)
> > -             type = BPF_CGROUP_INET_INGRESS;
> > -     if (bpf_prog_attach(bpfprog_fd, cg1, type, 0)) {
> > -             printf("ERROR: bpf_prog_attach fails!\n");
> > -             log_err("Attaching prog");
> > +             bpf_program__set_expected_attach_type(bpf_prog, BPF_CGROUP_INET_INGRESS);
> > +
> > +     link = bpf_program__attach_cgroup(bpf_prog, cg1);
> There is a difference here.
> I think the bpf_prog will be detached when link is gone (e.g. process exit)
> I am not sure it is what hbm is expected considering
> cg is not clean-up on the success case.
>

I think you're right. As I did in the third patch, I will use the
link__pin approach to prevent the link from being cleaned up when the
process exit.

> > +     if (libbpf_get_error(link)) {
> > +             fprintf(stderr, "ERROR: bpf_program__attach_cgroup failed\n");
> > +             link = NULL;
> not needed.  bpf_link__destroy() can handle err ptr.
>

Thank you for the detailed advice, but in order to make it more clear
that link is no longer used, how about keeping this approach?

> >               goto err;
> >       }
> > [...]
> > +
> >       if (cg1)
> This test looks wrong since cg1 is a fd.
>

I'll remove unnecessary fd compare.

-- 
Best,
Daniel T. Lee