Re: [PATCH bpf-next v2 2/2] selftests/bpf: Excercise bpf_obj_get_info_by_fd for bpf2bpf

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

 



On Tue, Aug 2, 2022 at 9:21 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
>
> On Mon, Aug 1, 2022 at 2:44 PM Andrii Nakryiko
> <andrii.nakryiko@xxxxxxxxx> wrote:
> >
> > On Mon, Aug 1, 2022 at 10:39 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
> > >
> > > Apparently, no existing selftest covers it. Add a new one where
> > > we load cgroup/bind4 program and attach fentry to it.
> > > Calling bpf_obj_get_info_by_fd on the fentry program
> > > should return non-zero btf_id/btf_obj_id instead of crashing the kernel.
> > >
> > > v2:
> > > - use ret instead of err in find_prog_btf_id (Hao)
> > > - remove verifier log (Hao)
> > > - drop if conditional from ASSERT_OK(bpf_obj_get_info_by_fd(...)) (Hao)
> > >
> > > Signed-off-by: Stanislav Fomichev <sdf@xxxxxxxxxx>
> > > ---
> > >  .../selftests/bpf/prog_tests/attach_to_bpf.c  | 97 +++++++++++++++++++
> > >  .../selftests/bpf/progs/attach_to_bpf.c       | 12 +++
> > >  2 files changed, 109 insertions(+)
> > >  create mode 100644 tools/testing/selftests/bpf/prog_tests/attach_to_bpf.c
> > >  create mode 100644 tools/testing/selftests/bpf/progs/attach_to_bpf.c
> > >
> >
> > [...]
> >
> > > +
> > > +       ret = btf__find_by_name_kind(btf, name, BTF_KIND_FUNC);
> > > +       btf__free(btf);
> > > +       return ret;
> > > +}
> > > +
> > > +int load_fentry(int attach_prog_fd, int attach_btf_id)
> >
> > static?
> >
> > > +{
> > > +       LIBBPF_OPTS(bpf_prog_load_opts, opts,
> > > +                   .expected_attach_type = BPF_TRACE_FENTRY,
> > > +                   .attach_prog_fd = attach_prog_fd,
> > > +                   .attach_btf_id = attach_btf_id,
> > > +       );
> > > +       struct bpf_insn insns[] = {
> > > +               BPF_MOV64_IMM(BPF_REG_0, 0),
> > > +               BPF_EXIT_INSN(),
> > > +       };
> > > +
> > > +       return bpf_prog_load(BPF_PROG_TYPE_TRACING,
> > > +                            "bind4_fentry",
> > > +                            "GPL",
> > > +                            insns,
> > > +                            ARRAY_SIZE(insns),
> > > +                            &opts);
> > > +}
> > > +
> > > +void test_attach_to_bpf(void)
> > > +{
> > > +       struct attach_to_bpf *skel = NULL;
> > > +       struct bpf_prog_info info = {};
> > > +       __u32 info_len = sizeof(info);
> > > +       int cgroup_fd = -1;
> > > +       int fentry_fd = -1;
> > > +       int btf_id;
> > > +
> > > +       cgroup_fd = test__join_cgroup("/attach_to_bpf");
> > > +       if (!ASSERT_GE(cgroup_fd, 0, "cgroup_fd"))
> > > +               return;
> > > +
> > > +       skel = attach_to_bpf__open_and_load();
> > > +       if (!ASSERT_OK_PTR(skel, "skel"))
> > > +               goto cleanup;
> > > +
> > > +       skel->links.bind4 = bpf_program__attach_cgroup(skel->progs.bind4, cgroup_fd);
> > > +       if (!ASSERT_OK_PTR(skel, "bpf_program__attach_cgroup"))
> >
> > you probably meant to check skel->links.bind4 instead of just skel
> > (which you already checked)
>
> Oh, good catch, thanks!
>
> > > +               goto cleanup;
> > > +
> > > +       btf_id = find_prog_btf_id("bind4", bpf_program__fd(skel->progs.bind4));
> > > +       if (!ASSERT_GE(btf_id, 0, "find_prog_btf_id"))
> > > +               goto cleanup;
> > > +
> > > +       fentry_fd = load_fentry(bpf_program__fd(skel->progs.bind4), btf_id);
> > > +       if (!ASSERT_GE(fentry_fd, 0, "load_fentry"))
> > > +               goto cleanup;
> > > +
> > > +       /* Make sure bpf_obj_get_info_by_fd works correctly when attaching
> > > +        * to another BPF program.
> > > +        */
> > > +
> > > +       ASSERT_OK(bpf_obj_get_info_by_fd(fentry_fd, &info, &info_len),
> > > +                 "bpf_obj_get_info_by_fd");
> > > +
> > > +       ASSERT_EQ(info.btf_id, 0, "info.btf_id");
> > > +       ASSERT_GT(info.attach_btf_id, 0, "info.attach_btf_id");
> > > +       ASSERT_GT(info.attach_btf_obj_id, 0, "info.attach_btf_obj_id");
> > > +
> > > +cleanup:
> >
> > if (cgroup_fd >= 0)
> >
> > > +       close(cgroup_fd);
> >
> > if (fentry_fd >= 0)
>
> Should be safe to do unconditional close(-1), right? Why bother with
> the checks here? Seems like a common pattern we do elsewhere?
>

I don't think we consciously do close(-1), libbpf definitely tries
hard to not attempt to close invalid fd, and so do (most?) of
selftests. Where do you see use doing close(-1)?

> > > +       close(fentry_fd);
> > > +       attach_to_bpf__destroy(skel);
> > > +}
> > > diff --git a/tools/testing/selftests/bpf/progs/attach_to_bpf.c b/tools/testing/selftests/bpf/progs/attach_to_bpf.c
> > > new file mode 100644
> > > index 000000000000..3f111fe96f8f
> > > --- /dev/null
> > > +++ b/tools/testing/selftests/bpf/progs/attach_to_bpf.c
> > > @@ -0,0 +1,12 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +#include <linux/bpf.h>
> > > +#include <bpf/bpf_helpers.h>
> > > +
> > > +SEC("cgroup/bind4")
> > > +int bind4(struct bpf_sock_addr *ctx)
> > > +{
> > > +       return 1;
> > > +}
> > > +
> > > +char _license[] SEC("license") = "GPL";
> > > --
> > > 2.37.1.455.g008518b4e5-goog
> > >



[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