On Wed, Jul 9, 2025 at 4:08 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Jul 3, 2025 at 5:18 AM Menglong Dong <menglong8.dong@xxxxxxxxx> wrote: > > > > + return true; > > + > > + /* Following symbols have multi definition in kallsyms, take > > + * "t_next" for example: > > + * > > + * ffffffff813c10d0 t t_next > > + * ffffffff813d31b0 t t_next > > + * ffffffff813e06b0 t t_next > > + * ffffffff813eb360 t t_next > > + * ffffffff81613360 t t_next > > + * > > + * but only one of them have corresponding mrecord: > > + * ffffffff81613364 t_next > > + * > > + * The kernel search the target function address by the symbol > > + * name "t_next" with kallsyms_lookup_name() during attaching > > + * and the function "0xffffffff813c10d0" can be matched, which > > + * doesn't have a corresponding mrecord. And this will make > > + * the attach failing. Skip the functions like this. > > + * > > + * The list maybe not whole, so we still can fail......We need a > > + * way to make the whole things right. Yes, we need fix it :/ > > + */ > > + if (!strcmp(name, "kill_pid_usb_asyncio")) > > + return true; > > + if (!strcmp(name, "t_next")) > > + return true; > > + if (!strcmp(name, "t_stop")) > > + return true; > > This looks like pahole bug. It shouldn't emit BTF for static > functions with the same name in different files. > I recall we discussed it in the past and I thought the fix had landed. I have tested the latest pahole, and it seems it hasn't been fixed yet. I sent a patch to relieve this problem in the kernel side: https://lore.kernel.org/bpf/20250708072140.945296-1-dongml2@xxxxxxxxxxxxxxx/ It's not perfect, but it can still be of some use in this problem.
