Re: [PATCH 2/2] kernel/bpf/verifier: Support module kfunc resolution via instruction offset

[Song Chen]

Hi,

On 4/30/26 14:27, bot+bpf-ci@xxxxxxxxxx wrote:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 03f9e16c2abe..7e6a95e6821d 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -2734,7 +2734,10 @@ int bpf_add_kfunc_call(struct bpf_verifier_env *env, u32 func_id, u16 offset)
> >   	if (err)
> >   		return err;
> >
> > -	addr = kallsyms_lookup_name(kfunc.name);
> > +	if (offset)
> > +		addr = module_kallsyms_lookup_name(kfunc.name);
> > +	else
> > +		addr = kallsyms_lookup_name(kfunc.name);
> >   	if (!addr) {
> >   		verbose(env, "cannot find address for kernel function %s\n", kfunc.name);
> >   		return -EINVAL;
>
> When offset is non-zero, module_kallsyms_lookup_name(kfunc.name) searches
> all loaded modules and returns the first match. How does this handle the
> case where multiple modules register kfuncs with the same name?
>
> In the original discussion thread from January 2026, Alexei Starovoitov
> asked: "but what about kfunc in module A with the same name as kfunc in
> module B?" You acknowledged this concern and indicated it was in your plan
> to address. However, the current implementation appears to rely on module
> load order when multiple modules have identically-named kfuncs.
>
> Reference: https://lore.kernel.org/all/CAADnVQLVQW-Mb_d+zT+aSpPOZ042erPVcSHVBx9PMGET+a754Q@xxxxxxxxxxxxxx/

This problem is in my mind too, but as far as my understanding, the ebpf 
code of calling an kfunc is:

85 10 00 00 ff ff ff ff

when libbpf relocates this kfunc, it searches all the modules only by 
obj->externs[i]->name, no additional indication tells libbpf which 
module to search from, as a result, the first finding will be relocated 
in ebpf code, like:

code=0x85 dst=0 src=2 off=1 imm=153416

> Is there a mechanism to ensure the correct module's kfunc is selected when
> names collide across different modules?

Is it acceptable to add extra information in ebpf source code when it's 
calling a kfun:

extern int module_a__foo(void *p) __ksym;
extern int module_b__foo(void *p) __ksym;
extern int foo(void *p) __ksym;

Then libbpf interprets obj->externs[i]->name and knows which module or 
vmlinux this kfunc belongs to, kernel will find the correct addr in 
verifier.

Best regards,

/Song

> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25150033548