On Tue, May 04, 2021 at 09:42:49PM -0700, Alexei Starovoitov wrote:

On Tue, May 4, 2021 at 5:36 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Tue, May 4, 2021 at 6:32 AM Jiri Olsa [off-list ref] wrote:

quoted

On Mon, May 03, 2021 at 03:45:28PM -0700, Andrii Nakryiko wrote:

quoted

On Fri, Apr 30, 2021 at 6:48 AM Jiri Olsa [off-list ref] wrote:

quoted

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