On Fri, Mar 24, 2023 at 8:01 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > > On 03/24, Andrii Nakryiko wrote: > > If user explicitly overrides programs's type with > > bpf_program__set_type() API call, we need to disassociate whatever > > SEC_DEF handler libbpf determined initially based on program's SEC() > > definition, as it's not goind to be valid anymore and could lead to > > crashes and/or confusing failures. > > > Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx> > > --- > > tools/lib/bpf/libbpf.c | 1 + > > 1 file changed, 1 insertion(+) > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > > index f6a071db5c6e..a34ebb6b8508 100644 > > --- a/tools/lib/bpf/libbpf.c > > +++ b/tools/lib/bpf/libbpf.c > > @@ -8465,6 +8465,7 @@ int bpf_program__set_type(struct bpf_program *prog, > > enum bpf_prog_type type) > > return libbpf_err(-EBUSY); > > > prog->type = type; > > + prog->sec_def = NULL; > > return 0; > > } > > Surprisingly, but it breaks the following selftest: > > serial_test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec > serial_test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec > serial_test_bpf_obj_id:PASS:get-fd-by-notexist-link-id 0 nsec > serial_test_bpf_obj_id:FAIL:prog_attach prog #0, err -95 > #17 bpf_obj_id:FAIL > > (saw in the bot, reproduced locally) > my bad for not testing thoroughly enough, will take a look at what's going on, thanks! > > -- > > 2.34.1 >
