On Tue, May 4, 2021 at 5:36 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Tue, May 4, 2021 at 6:32 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > On Mon, May 03, 2021 at 03:45:28PM -0700, Andrii Nakryiko wrote: > > > On Fri, Apr 30, 2021 at 6:48 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > > > > > There are 2 mm_init functions in kernel. > > > > > > > > One in kernel/fork.c: > > > > static struct mm_struct *mm_init(struct mm_struct *mm, > > > > struct task_struct *p, > > > > struct user_namespace *user_ns) > > > > > > > > And another one in init/main.c: > > > > static void __init mm_init(void) > > > > > > > > The BTF data will get the first one, which is most likely > > > > (in my case) mm_init from init/main.c without arguments. did you hack pahole in some way to get to this point? I don't see this with pahole master. mm_init in BTF matches the one in init/main.c. The void one. Do you have two static mm_init-s in BTF somehow? In general it's possible to have different static funcs with the same name in kallsyms. I found 3 'seq_start' in my .config. So renaming static funcs is not an option. The simplest approach for now is to avoid emitting BTF if there is more than one func (that will prevent attaching because there won't be any BTF for that func). Long term I think BTF can store the .text offset and the verifier can avoid kallsym lookup. We do store insn_off in bpf_func_info for bpf progs. Something like this could be done for kernel and module funcs. But that's long term.
