On Tue, May 04, 2021 at 09:42:49PM -0700, Alexei Starovoitov wrote: > 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? I have only one mm_init in BTF from init/main.c like you, but the address in kallsyms is for the mm_init from kernel/fork.c so we attach mm_init from kernel/fork.c with prototype from init/main.c I'm seeing same problem also for 'receive_buf' function, which I did not post > > 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). sounds good.. will prepare the pahole change > 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. > ok, will check on this jirka
