On Mon, Aug 1, 2022 at 10:45 AM Martin KaFai Lau <kafai@xxxxxx> wrote:
>
> On Fri, Jul 29, 2022 at 05:08:09PM -0700, Stanislav Fomichev 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.
> >
> > Signed-off-by: Stanislav Fomichev <sdf@xxxxxxxxxx>
> > ---
> > .../selftests/bpf/prog_tests/attach_to_bpf.c | 109 ++++++++++++++++++
> > .../selftests/bpf/progs/attach_to_bpf.c | 12 ++
> > 2 files changed, 121 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
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/attach_to_bpf.c b/tools/testing/selftests/bpf/prog_tests/attach_to_bpf.c
> > new file mode 100644
> > index 000000000000..fcf726c5ff0f
> > --- /dev/null
> > +++ b/tools/testing/selftests/bpf/prog_tests/attach_to_bpf.c
> > @@ -0,0 +1,109 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +#define _GNU_SOURCE
> > +#include <stdlib.h>
> > +#include <bpf/btf.h>
> > +#include <test_progs.h>
> > +#include <network_helpers.h>
> > +#include "attach_to_bpf.skel.h"
> > +
> > +char bpf_log_buf[BPF_LOG_BUF_SIZE];
> static
Will remove bpf_log_buf. Sent v2 too soon :-(
> > +
> > +static int find_prog_btf_id(const char *name, __u32 attach_prog_fd)
> > +{
> > + struct bpf_prog_info info = {};
> > + __u32 info_len = sizeof(info);
> > + struct btf *btf;
> > + int err;
> > +
> > + err = bpf_obj_get_info_by_fd(attach_prog_fd, &info, &info_len);
> > + if (err)
> > + return err;
> > +
> > + if (!info.btf_id)
> > + return -EINVAL;
> > +
> > + btf = btf__load_from_kernel_by_id(info.btf_id);
> > + err = libbpf_get_error(btf);
> > + if (err)
> > + return err;
> > +
> > + err = btf__find_by_name_kind(btf, name, BTF_KIND_FUNC);
> > + btf__free(btf);
> > + if (err <= 0)
> > + return err;
> > +
> > + return err;
> > +}
> > +
> > +int load_fentry(int attach_prog_fd, int attach_btf_id)
> static
Thx!
> > +{
> > + 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,
> > + .log_buf = bpf_log_buf,
> > + .log_size = sizeof(bpf_log_buf),
> > + );
> > + struct bpf_insn insns[] = {
> > + BPF_MOV64_IMM(BPF_REG_0, 0),
> > + BPF_EXIT_INSN(),
> > + };
> > + int ret;
> > +
> > + ret = bpf_prog_load(BPF_PROG_TYPE_TRACING,
> > + "bind4_fentry",
> > + "GPL",
> > + insns,
> > + ARRAY_SIZE(insns),
> > + &opts);
> > + if (ret)
> > + printf("verifier log: %s\n", bpf_log_buf);
> If this fentry prog is in the attach_to_bpf.c and load by skel, this printf
> and the bpf_log_buf can go away. I wonder if it can use the '?' like
> SEC("?cgroup/bind4") and SEC("?fentry"). Then opens attach_to_bpf.skel.h
> twice and use bpf_program__set_autoload() to load individual program .
Good ideal, let me try to see if doing "?fentry" is easier..
(unless we agree to keep load_fentry, see below)
> Another option could be to reuse the progs/bind4_prog.c and directly
> put the fentry program in the attach_to_bpf.c.
>
> btw, this test feels like something that could be a few line
> addition to the test_fexit_bpf2bpf_common() in fexit_bpf2bpf.c.
> Adding one to test fentry into a cgroup bpf prog is also good.
> No strong opinion here also.
I was trying to reuse fexit_bpf2bpf initially but I sank too much time
into it and decided that it might be easier to write a
simpler/separate reproducer instead :-(
How about we reuse progs/bind4_prog.c and keep load_fentry() ? And put
this new test in fexit_bpf2bpf.c ?
