Re: [xdp-hints] Re: [PATCH bpf-next v3 03/12] bpf: XDP metadata RX kfuncs

[Martin KaFai Lau <martin.lau@linux.dev>]

On 12/8/22 6:57 PM, Stanislav Fomichev wrote:
> On Thu, Dec 8, 2022 at 4:07 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Stanislav Fomichev <sdf@google.com> 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?

hmm.... if I follow correctly, it wants the libbpf to accept a bpf prog using a 
kfunc that does not exist in the running kernel?

Have you tried "__weak":

extern void dummy_kfunc(void) __ksym __weak;

SEC("tc")
int load(struct __sk_buff *skb)
{
	if (dummy_kfunc) {
		dummy_kfunc();
		return TC_ACT_SHOT;
	}
	return TC_ACT_UNSPEC;
}