On Thu, Dec 8, 2022 at 4:07 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Stanislav Fomichev <sdf@xxxxxxxxxx> writes: > > >> Another UX thing I ran into is that libbpf will bail out if it can't > >> find the kfunc in the kernel vmlinux, even if the code calling the > >> function is behind an always-false if statement (which would be > >> eliminated as dead code from the verifier). This makes it a bit hard to > >> conditionally use them. Should libbpf just allow the load without > >> performing the relocation (and let the verifier worry about it), or > >> should we have a bpf_core_kfunc_exists() macro to use for checking? > >> Maybe both? > > > > I'm not sure how libbpf can allow the load without performing the > > relocation; maybe I'm missing something. > > IIUC, libbpf uses the kfunc name (from the relocation?) and replaces > > it with the kfunc id, right? > > Yeah, so if it can't find the kfunc in vmlinux, just write an id of 0. > This will trip the check at the top of fixup_kfunc_call() in the > verifier, but if the code is hidden behind an always-false branch (an > rodata variable set to zero, say) the instructions should get eliminated > before they reach that point. That way you can at least turn it off at > runtime (after having done some kind of feature detection) without > having to compile it out of your program entirely. > > > Having bpf_core_kfunc_exists would help, but this probably needs > > compiler work first to preserve some of the kfunc traces in vmlinux.h? > > I am not sure how the existing macros work, TBH. Hopefully someone else > can chime in :) +1 I think we need to poke Andrii as a follow up :-) > -Toke >
