* [PATCH bpf-next 0/2] Fix attaching fentry/fexit/fmod_ret/lsm to modules @ 2022-11-28 7:26 Viktor Malik 2022-11-28 7:26 ` [PATCH bpf-next 1/2] bpf: " Viktor Malik 2022-11-28 7:26 ` [PATCH bpf-next 2/2] bpf/selftests: Test fentry attachment to shadowed functions Viktor Malik 0 siblings, 2 replies; 6+ messages in thread From: Viktor Malik @ 2022-11-28 7:26 UTC (permalink / raw) To: bpf Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Viktor Malik While working on bpftrace support for BTF in modules [1], I noticed that the verifier behaves incorrectly when attaching to fentry of multiple functions of the same name located in different modules (or in vmlinux). The reason for this is that if the target program is not specified, the verifier will search kallsyms for the trampoline address to attach to. The entire kallsyms is always searched, not respecting the module in which the function to attach to is located. This patch fixes the above issue by extracting the module name from the BTF of the attachment target (which must be specified) and by doing the search in kallsyms of the correct module. This also adds a new test in test_progs which tries to attach a program to fentry of two functions of the same name, one located in vmlinux and the other in bpf_testmod. Prior to the fix, the verifier would always use the vmlinux function address as the target trampoline, attempting to attach two functions to the same trampoline (which is prohibited). [1] https://github.com/iovisor/bpftrace/pull/2315 Viktor Malik (2): bpf: Fix attaching fentry/fexit/fmod_ret/lsm to modules bpf/selftests: Test fentry attachment to shadowed functions include/linux/btf.h | 1 + kernel/bpf/btf.c | 5 + kernel/bpf/verifier.c | 9 +- net/bpf/test_run.c | 5 + .../selftests/bpf/bpf_testmod/bpf_testmod.c | 7 + .../bpf/prog_tests/module_attach_shadow.c | 120 ++++++++++++++++++ 6 files changed, 146 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c -- 2.38.1 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH bpf-next 1/2] bpf: Fix attaching fentry/fexit/fmod_ret/lsm to modules 2022-11-28 7:26 [PATCH bpf-next 0/2] Fix attaching fentry/fexit/fmod_ret/lsm to modules Viktor Malik @ 2022-11-28 7:26 ` Viktor Malik 2022-11-28 9:07 ` Jiri Olsa 2022-11-28 7:26 ` [PATCH bpf-next 2/2] bpf/selftests: Test fentry attachment to shadowed functions Viktor Malik 1 sibling, 1 reply; 6+ messages in thread From: Viktor Malik @ 2022-11-28 7:26 UTC (permalink / raw) To: bpf Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Viktor Malik When attaching fentry/fexit/fmod_ret/lsm to a function located in a module without specifying the target program, the verifier tries to find the address to attach to in kallsyms. This is always done by searching the entire kallsyms, not respecting the module in which the function is located. This approach causes an incorrect attachment address to be computed if the function to attach to is shadowed by a function of the same name located earlier in kallsyms. Since the attachment must contain the BTF of the program to attach to, we may extract the module name from it (if the attach target is a module) and search for the function address in the correct module. Signed-off-by: Viktor Malik <vmalik@redhat.com> --- include/linux/btf.h | 1 + kernel/bpf/btf.c | 5 +++++ kernel/bpf/verifier.c | 9 ++++++++- 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/include/linux/btf.h b/include/linux/btf.h index 9ed00077db6e..bdbf3eb7083d 100644 --- a/include/linux/btf.h +++ b/include/linux/btf.h @@ -187,6 +187,7 @@ u32 btf_obj_id(const struct btf *btf); bool btf_is_kernel(const struct btf *btf); bool btf_is_module(const struct btf *btf); struct module *btf_try_get_module(const struct btf *btf); +const char *btf_module_name(const struct btf *btf); u32 btf_nr_types(const struct btf *btf); bool btf_member_is_reg_int(const struct btf *btf, const struct btf_type *s, const struct btf_member *m, diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index 1a59cc7ad730..211fcbb7649d 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -7192,6 +7192,11 @@ bool btf_is_module(const struct btf *btf) return btf->kernel_btf && strcmp(btf->name, "vmlinux") != 0; } +const char *btf_module_name(const struct btf *btf) +{ + return btf->name; +} + enum { BTF_MODULE_F_LIVE = (1 << 0), }; diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 9528a066cfa5..acbe62a73559 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -16343,7 +16343,14 @@ int bpf_check_attach_target(struct bpf_verifier_log *log, else addr = (long) tgt_prog->aux->func[subprog]->bpf_func; } else { - addr = kallsyms_lookup_name(tname); + if (btf_is_module(btf)) { + char tmodname[MODULE_NAME_LEN + KSYM_NAME_LEN + 1]; + snprintf(tmodname, sizeof(tmodname), "%s:%s", + btf_module_name(btf), tname); + addr = module_kallsyms_lookup_name(tmodname); + } + else + addr = kallsyms_lookup_name(tname); if (!addr) { bpf_log(log, "The address of function %s cannot be found\n", -- 2.38.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next 1/2] bpf: Fix attaching fentry/fexit/fmod_ret/lsm to modules 2022-11-28 7:26 ` [PATCH bpf-next 1/2] bpf: " Viktor Malik @ 2022-11-28 9:07 ` Jiri Olsa 2022-11-28 20:06 ` Hao Luo 0 siblings, 1 reply; 6+ messages in thread From: Jiri Olsa @ 2022-11-28 9:07 UTC (permalink / raw) To: Viktor Malik Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo On Mon, Nov 28, 2022 at 08:26:29AM +0100, Viktor Malik wrote: > When attaching fentry/fexit/fmod_ret/lsm to a function located in a > module without specifying the target program, the verifier tries to find > the address to attach to in kallsyms. This is always done by searching > the entire kallsyms, not respecting the module in which the function is > located. > > This approach causes an incorrect attachment address to be computed if > the function to attach to is shadowed by a function of the same name > located earlier in kallsyms. > > Since the attachment must contain the BTF of the program to attach to, > we may extract the module name from it (if the attach target is a > module) and search for the function address in the correct module. > > Signed-off-by: Viktor Malik <vmalik@redhat.com> > --- > include/linux/btf.h | 1 + > kernel/bpf/btf.c | 5 +++++ > kernel/bpf/verifier.c | 9 ++++++++- > 3 files changed, 14 insertions(+), 1 deletion(-) > > diff --git a/include/linux/btf.h b/include/linux/btf.h > index 9ed00077db6e..bdbf3eb7083d 100644 > --- a/include/linux/btf.h > +++ b/include/linux/btf.h > @@ -187,6 +187,7 @@ u32 btf_obj_id(const struct btf *btf); > bool btf_is_kernel(const struct btf *btf); > bool btf_is_module(const struct btf *btf); > struct module *btf_try_get_module(const struct btf *btf); > +const char *btf_module_name(const struct btf *btf); > u32 btf_nr_types(const struct btf *btf); > bool btf_member_is_reg_int(const struct btf *btf, const struct btf_type *s, > const struct btf_member *m, > diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c > index 1a59cc7ad730..211fcbb7649d 100644 > --- a/kernel/bpf/btf.c > +++ b/kernel/bpf/btf.c > @@ -7192,6 +7192,11 @@ bool btf_is_module(const struct btf *btf) > return btf->kernel_btf && strcmp(btf->name, "vmlinux") != 0; > } > > +const char *btf_module_name(const struct btf *btf) > +{ > + return btf->name; > +} > + > enum { > BTF_MODULE_F_LIVE = (1 << 0), > }; > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > index 9528a066cfa5..acbe62a73559 100644 > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -16343,7 +16343,14 @@ int bpf_check_attach_target(struct bpf_verifier_log *log, > else > addr = (long) tgt_prog->aux->func[subprog]->bpf_func; > } else { > - addr = kallsyms_lookup_name(tname); > + if (btf_is_module(btf)) { > + char tmodname[MODULE_NAME_LEN + KSYM_NAME_LEN + 1]; looks good.. would be nice to have module_kallsyms lookup function that takes module name and symbol separately so we won't waste stack on that.. especially when module_kallsyms_lookup_name just separates it back again and does module lookup.. but not sure how much pain it'd be jirka > + snprintf(tmodname, sizeof(tmodname), "%s:%s", > + btf_module_name(btf), tname); > + addr = module_kallsyms_lookup_name(tmodname); > + } > + else > + addr = kallsyms_lookup_name(tname); > if (!addr) { > bpf_log(log, > "The address of function %s cannot be found\n", > -- > 2.38.1 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next 1/2] bpf: Fix attaching fentry/fexit/fmod_ret/lsm to modules 2022-11-28 9:07 ` Jiri Olsa @ 2022-11-28 20:06 ` Hao Luo 0 siblings, 0 replies; 6+ messages in thread From: Hao Luo @ 2022-11-28 20:06 UTC (permalink / raw) To: Jiri Olsa Cc: Viktor Malik, bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev On Mon, Nov 28, 2022 at 1:07 AM Jiri Olsa <olsajiri@gmail.com> wrote: > > On Mon, Nov 28, 2022 at 08:26:29AM +0100, Viktor Malik wrote: > > When attaching fentry/fexit/fmod_ret/lsm to a function located in a > > module without specifying the target program, the verifier tries to find > > the address to attach to in kallsyms. This is always done by searching > > the entire kallsyms, not respecting the module in which the function is > > located. > > > > This approach causes an incorrect attachment address to be computed if > > the function to attach to is shadowed by a function of the same name > > located earlier in kallsyms. > > > > Since the attachment must contain the BTF of the program to attach to, > > we may extract the module name from it (if the attach target is a > > module) and search for the function address in the correct module. > > > > Signed-off-by: Viktor Malik <vmalik@redhat.com> > > --- > > include/linux/btf.h | 1 + > > kernel/bpf/btf.c | 5 +++++ > > kernel/bpf/verifier.c | 9 ++++++++- > > 3 files changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/btf.h b/include/linux/btf.h > > index 9ed00077db6e..bdbf3eb7083d 100644 > > --- a/include/linux/btf.h > > +++ b/include/linux/btf.h > > @@ -187,6 +187,7 @@ u32 btf_obj_id(const struct btf *btf); > > bool btf_is_kernel(const struct btf *btf); > > bool btf_is_module(const struct btf *btf); > > struct module *btf_try_get_module(const struct btf *btf); > > +const char *btf_module_name(const struct btf *btf); > > u32 btf_nr_types(const struct btf *btf); > > bool btf_member_is_reg_int(const struct btf *btf, const struct btf_type *s, > > const struct btf_member *m, > > diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c > > index 1a59cc7ad730..211fcbb7649d 100644 > > --- a/kernel/bpf/btf.c > > +++ b/kernel/bpf/btf.c > > @@ -7192,6 +7192,11 @@ bool btf_is_module(const struct btf *btf) > > return btf->kernel_btf && strcmp(btf->name, "vmlinux") != 0; > > } > > > > +const char *btf_module_name(const struct btf *btf) > > +{ > > + return btf->name; > > +} > > + > > enum { > > BTF_MODULE_F_LIVE = (1 << 0), > > }; > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index 9528a066cfa5..acbe62a73559 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -16343,7 +16343,14 @@ int bpf_check_attach_target(struct bpf_verifier_log *log, > > else > > addr = (long) tgt_prog->aux->func[subprog]->bpf_func; > > } else { > > - addr = kallsyms_lookup_name(tname); > > + if (btf_is_module(btf)) { > > + char tmodname[MODULE_NAME_LEN + KSYM_NAME_LEN + 1]; > > looks good.. would be nice to have module_kallsyms lookup function that > takes module name and symbol separately so we won't waste stack on that.. > > especially when module_kallsyms_lookup_name just separates it back again > and does module lookup.. but not sure how much pain it'd be > > jirka > > > + snprintf(tmodname, sizeof(tmodname), "%s:%s", > > + btf_module_name(btf), tname); > > + addr = module_kallsyms_lookup_name(tmodname); > > + } > > + else > > + addr = kallsyms_lookup_name(tname); In addition to what Jiri suggested, we should also have brackets in the 'else' branch. if (...) { ... } else { ... } > > if (!addr) { > > bpf_log(log, > > "The address of function %s cannot be found\n", > > -- > > 2.38.1 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH bpf-next 2/2] bpf/selftests: Test fentry attachment to shadowed functions 2022-11-28 7:26 [PATCH bpf-next 0/2] Fix attaching fentry/fexit/fmod_ret/lsm to modules Viktor Malik 2022-11-28 7:26 ` [PATCH bpf-next 1/2] bpf: " Viktor Malik @ 2022-11-28 7:26 ` Viktor Malik 2022-11-28 21:14 ` Hao Luo 1 sibling, 1 reply; 6+ messages in thread From: Viktor Malik @ 2022-11-28 7:26 UTC (permalink / raw) To: bpf Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Viktor Malik Adds a new test that tries to attach a program to fentry of two functions of the same name, one located in vmlinux and the other in bpf_testmod. To avoid conflicts with existing tests, a new function "bpf_fentry_shadow_test" was created both in vmlinux and in bpf_testmod. The previous commit fixed a bug which caused this test to fail. The verifier would always use the vmlinux function's address as the target trampoline address, hence trying to attach two programs to the same trampoline. Signed-off-by: Viktor Malik <vmalik@redhat.com> --- net/bpf/test_run.c | 5 + .../selftests/bpf/bpf_testmod/bpf_testmod.c | 7 + .../bpf/prog_tests/module_attach_shadow.c | 120 ++++++++++++++++++ 3 files changed, 132 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c index 6fba440efc40..c60e46b1e768 100644 --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -536,6 +536,11 @@ int noinline bpf_modify_return_test(int a, int *b) return a + *b; } +int noinline bpf_fentry_shadow_test(int a) +{ + return a + 1; +} + u64 noinline bpf_kfunc_call_test1(struct sock *sk, u32 a, u64 b, u32 c, u64 d) { return a + b + c + d; diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c index 5085fea3cac5..d23127a5ec68 100644 --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c @@ -229,6 +229,13 @@ static const struct btf_kfunc_id_set bpf_testmod_kfunc_set = { .set = &bpf_testmod_check_kfunc_ids, }; +noinline int bpf_fentry_shadow_test(int a) +{ + return a + 2; +} +EXPORT_SYMBOL_GPL(bpf_fentry_shadow_test); +ALLOW_ERROR_INJECTION(bpf_fentry_shadow_test, ERRNO); + extern int bpf_fentry_test1(int a); static int bpf_testmod_init(void) diff --git a/tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c b/tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c new file mode 100644 index 000000000000..0c604a0f22ca --- /dev/null +++ b/tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c @@ -0,0 +1,120 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) 2022 Red Hat */ +#include <test_progs.h> +#include <bpf/btf.h> +#include "bpf/libbpf_internal.h" +#include "cgroup_helpers.h" + +static const char *module_name = "bpf_testmod"; +static const char *symbol_name = "bpf_fentry_shadow_test"; + +int get_bpf_testmod_btf_fd(void) +{ + struct bpf_btf_info info; + char name[64]; + __u32 id, len; + int err, fd; + + while (true) { + err = bpf_btf_get_next_id(id, &id); + if (err) { + log_err("failed to iterate BTF objects"); + return err; + } + + fd = bpf_btf_get_fd_by_id(id); + if (fd < 0) { + err = -errno; + log_err("failed to get FD for BTF object #%d", id); + return err; + } + + len = sizeof(info); + memset(&info, 0, sizeof(info)); + info.name = ptr_to_u64(name); + info.name_len = sizeof(name); + + err = bpf_obj_get_info_by_fd(fd, &info, &len); + if (err) { + err = -errno; + log_err("failed to get info for BTF object #%d", id); + close(fd); + return err; + } + + if (strcmp(name, module_name) == 0) + return fd; + + close(fd); + } + return -ENOENT; +} + +void test_module_fentry_shadow(void) +{ + struct btf *vmlinux_btf, *mod_btf; + int err, i; + int btf_fd[2] = {}; + int prog_fd[2] = {}; + int link_fd[2] = {}; + __s32 btf_id[2] = {}; + + const struct bpf_insn trace_program[] = { + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + }; + + LIBBPF_OPTS(bpf_prog_load_opts, load_opts, + .expected_attach_type = BPF_TRACE_FENTRY, + ); + + LIBBPF_OPTS(bpf_test_run_opts, test_opts); + + vmlinux_btf = btf__load_vmlinux_btf(); + if (!ASSERT_OK_PTR(vmlinux_btf, "load_vmlinux_btf")) + return; + + btf_fd[1] = get_bpf_testmod_btf_fd(); + if (!ASSERT_GT(btf_fd[1], 0, "get_bpf_testmod_btf_fd")) + return; + + mod_btf = btf_get_from_fd(btf_fd[1], vmlinux_btf); + if (!ASSERT_OK_PTR(mod_btf, "btf_get_from_fd")) + goto out; + + btf_id[0] = btf__find_by_name(vmlinux_btf, symbol_name); + if (!ASSERT_GT(btf_id[0], 0, "btf_find_by_name")) + goto out; + + btf_id[1] = btf__find_by_name(mod_btf, symbol_name); + if (!ASSERT_GT(btf_id[1], 0, "btf_find_by_name")) + goto out; + + for (i = 0; i < 2; i++) { + load_opts.attach_btf_id = btf_id[i]; + load_opts.attach_btf_obj_fd = btf_fd[i]; + prog_fd[i] = bpf_prog_load(BPF_PROG_TYPE_TRACING, NULL, "GPL", + trace_program, + sizeof(trace_program) / sizeof(struct bpf_insn), + &load_opts); + if (!ASSERT_GE(prog_fd[i], 0, "bpf_prog_load")) + goto out; + + link_fd[i] = bpf_link_create(prog_fd[i], 0, BPF_TRACE_FENTRY, NULL); + if (!ASSERT_GE(link_fd[i], 0, "bpf_link_create")) + goto out; + } + + err = bpf_prog_test_run_opts(prog_fd[0], &test_opts); + ASSERT_OK(err, "running test"); + +out: + for (i = 0; i < 2; i++) { + if (btf_fd[i]) + close(btf_fd[i]); + if (prog_fd[i]) + close(prog_fd[i]); + if (link_fd[i]) + close(link_fd[i]); + } +} -- 2.38.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH bpf-next 2/2] bpf/selftests: Test fentry attachment to shadowed functions 2022-11-28 7:26 ` [PATCH bpf-next 2/2] bpf/selftests: Test fentry attachment to shadowed functions Viktor Malik @ 2022-11-28 21:14 ` Hao Luo 0 siblings, 0 replies; 6+ messages in thread From: Hao Luo @ 2022-11-28 21:14 UTC (permalink / raw) To: Viktor Malik Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev, Jiri Olsa On Sun, Nov 27, 2022 at 11:26 PM Viktor Malik <vmalik@redhat.com> wrote: > > Adds a new test that tries to attach a program to fentry of two > functions of the same name, one located in vmlinux and the other in > bpf_testmod. > > To avoid conflicts with existing tests, a new function > "bpf_fentry_shadow_test" was created both in vmlinux and in bpf_testmod. > > The previous commit fixed a bug which caused this test to fail. The > verifier would always use the vmlinux function's address as the target > trampoline address, hence trying to attach two programs to the same > trampoline. > > Signed-off-by: Viktor Malik <vmalik@redhat.com> > --- <...> > diff --git a/tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c b/tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c > new file mode 100644 > index 000000000000..0c604a0f22ca > --- /dev/null > +++ b/tools/testing/selftests/bpf/prog_tests/module_attach_shadow.c > @@ -0,0 +1,120 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Copyright (c) 2022 Red Hat */ > +#include <test_progs.h> > +#include <bpf/btf.h> > +#include "bpf/libbpf_internal.h" > +#include "cgroup_helpers.h" > + > +static const char *module_name = "bpf_testmod"; > +static const char *symbol_name = "bpf_fentry_shadow_test"; > + > +int get_bpf_testmod_btf_fd(void) > +{ > + struct bpf_btf_info info; > + char name[64]; > + __u32 id, len; We need to initialize 'id'. > + int err, fd; <...> > +} > + > +void test_module_fentry_shadow(void) > +{ <...> > + > + btf_id[0] = btf__find_by_name(vmlinux_btf, symbol_name); > + if (!ASSERT_GT(btf_id[0], 0, "btf_find_by_name")) > + goto out; > + > + btf_id[1] = btf__find_by_name(mod_btf, symbol_name); btf__find_by_name_kind() may be better. It skips the name comparison if the kind doesn't match. > + if (!ASSERT_GT(btf_id[1], 0, "btf_find_by_name")) > + goto out; > + <...> > + err = bpf_prog_test_run_opts(prog_fd[0], &test_opts); > + ASSERT_OK(err, "running test"); > + > +out: We also need to btf__free vmlinux_btf and mod_btf. > + for (i = 0; i < 2; i++) { > + if (btf_fd[i]) > + close(btf_fd[i]); > + if (prog_fd[i]) > + close(prog_fd[i]); > + if (link_fd[i]) > + close(link_fd[i]); > + } > +} > -- > 2.38.1 > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-11-28 21:14 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-11-28 7:26 [PATCH bpf-next 0/2] Fix attaching fentry/fexit/fmod_ret/lsm to modules Viktor Malik 2022-11-28 7:26 ` [PATCH bpf-next 1/2] bpf: " Viktor Malik 2022-11-28 9:07 ` Jiri Olsa 2022-11-28 20:06 ` Hao Luo 2022-11-28 7:26 ` [PATCH bpf-next 2/2] bpf/selftests: Test fentry attachment to shadowed functions Viktor Malik 2022-11-28 21:14 ` Hao Luo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox