On 7/8/25 1:07 PM, Alexei Starovoitov 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 checked this particular case (the t_next function), and what seems
to be happening is that all function prototypes match, according to
this check in pahole's BTF encoding:
* https://github.com/acmel/dwarves/blob/v1.30/btf_encoder.c#L1378
* https://github.com/acmel/dwarves/blob/v1.30/btf_encoder.c#L1112-L1152
That is: the name, number and types of parameters all match.
So at least according to the current pahole logic the prototypes are
*consistent*. As a result, a single BTF function t_next is emitted.
Maybe funcs__match() check should be even more strict? Say, disallow
static functions?
I am not sure that the draft that Jiri sent [1] is right as it just
filters out duplicates by name.
[1] https://lore.kernel.org/bpf/aHD0IdJBqd3XNybw@krava/
