All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Menglong Dong <menglong8.dong@gmail.com>,
	Alan Maguire <alan.maguire@oracle.com>,
	Jiri Olsa <jolsa@kernel.org>, bpf <bpf@vger.kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	dwarves <dwarves@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 17/18] selftests/bpf: add basic testcases for tracing_multi
Date: Tue, 15 Jul 2025 17:34:59 -0700	[thread overview]
Message-ID: <b40a13d8-0fc9-44bd-a0c7-e656d0a14819@linux.dev> (raw)
In-Reply-To: <CAADnVQK-06d8E85aJ-=K+Af+a8_MSNJFiBqjpXYs4+adiTuwvw@mail.gmail.com>

On 7/15/25 5:31 PM, Alexei Starovoitov wrote:
> On Tue, Jul 15, 2025 at 5:27 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> On 7/14/25 4:49 PM, Ihor Solodrai wrote:
>>> On 7/8/25 1:07 PM, Alexei Starovoitov wrote:
>>>> On Thu, Jul 3, 2025 at 5:18 AM Menglong Dong
>>>> <menglong8.dong@gmail.com> 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 little patch will filter out from BTF any static functions with
>> the same name that appear more than once.
>>
>> diff --git a/btf_encoder.c b/btf_encoder.c
>> index 0bc2334..6441269 100644
>> --- a/btf_encoder.c
>> +++ b/btf_encoder.c
>> @@ -96,7 +96,8 @@ struct elf_function {
>>           const char      *name;
>>           char            *alias;
>>           size_t          prefixlen;
>> -       bool            kfunc;
>> +       uint8_t         is_static:1;
>> +       uint8_t         kfunc:1;
>>           uint32_t        kfunc_flags;
>>    };
>>
>> @@ -1374,7 +1375,7 @@ static int saved_functions_combine(struct
>> btf_encoder_func_state *a, struct btf_
>>                   return ret;
>>           optimized = a->optimized_parms | b->optimized_parms;
>>           unexpected = a->unexpected_reg | b->unexpected_reg;
>> -       inconsistent = a->inconsistent_proto | b->inconsistent_proto;
>> +       inconsistent = a->inconsistent_proto | b->inconsistent_proto |
>> a->elf->is_static | b->elf->is_static;
>>           if (!unexpected && !inconsistent && !funcs__match(a, b))
>>                   inconsistent = 1;
>>           a->optimized_parms = b->optimized_parms = optimized;
>> @@ -1461,6 +1462,8 @@ static void elf_functions__collect_function(struct
>> elf_functions *functions, GEl
>>
>>           func = &functions->entries[functions->cnt];
>>           func->name = name;
>> +       func->is_static = elf_sym__bind(sym) == STB_LOCAL;
>> +
> 
> Hmm. We definitely don't want to filter out all static functions.
> That's too drastic.

Not all static functions. Only those that match by name.


  reply	other threads:[~2025-07-16  0:35 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03 12:15 [PATCH bpf-next v2 00/18] bpf: tracing multi-link support Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 01/18] bpf: add function hash table for tracing-multi Menglong Dong
2025-07-04 16:07   ` kernel test robot
2025-07-15  1:55   ` Alexei Starovoitov
2025-07-15  2:37     ` Menglong Dong
2025-07-15  2:49       ` Alexei Starovoitov
2025-07-15  3:13         ` Menglong Dong
2025-07-15  9:06           ` Menglong Dong
2025-07-15 16:22             ` Alexei Starovoitov
2025-07-03 12:15 ` [PATCH bpf-next v2 02/18] x86,bpf: add bpf_global_caller for global trampoline Menglong Dong
2025-07-15  2:25   ` Alexei Starovoitov
2025-07-15  8:36     ` Menglong Dong
2025-07-15  9:30       ` Menglong Dong
2025-07-16 16:56         ` Inlining migrate_disable/enable. Was: " Alexei Starovoitov
2025-07-16 18:24           ` Peter Zijlstra
2025-07-16 22:35             ` Alexei Starovoitov
2025-07-16 22:49               ` Steven Rostedt
2025-07-16 22:50                 ` Steven Rostedt
2025-07-28  9:20               ` Menglong Dong
2025-07-31 16:15                 ` Alexei Starovoitov
2025-08-01  1:42                   ` Menglong Dong
2025-08-06  8:44                   ` Menglong Dong
2025-08-08  0:58                     ` Alexei Starovoitov
2025-08-08  5:48                       ` Menglong Dong
2025-08-08  6:32                       ` Menglong Dong
2025-08-08 15:47                         ` Alexei Starovoitov
2025-07-15 16:35       ` Alexei Starovoitov
2025-07-16 13:05         ` Menglong Dong
2025-07-17  0:59           ` multi-fentry proposal. Was: " Alexei Starovoitov
2025-07-17  1:50             ` Menglong Dong
2025-07-17  2:13               ` Alexei Starovoitov
2025-07-17  2:37                 ` Menglong Dong
2025-07-16 14:40         ` Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 03/18] ftrace: factor out ftrace_direct_update from register_ftrace_direct Menglong Dong
2025-07-05  2:41   ` kernel test robot
2025-07-03 12:15 ` [PATCH bpf-next v2 04/18] ftrace: add reset_ftrace_direct_ips Menglong Dong
2025-07-03 15:30   ` Steven Rostedt
2025-07-04  1:54     ` Menglong Dong
2025-07-07 18:52       ` Steven Rostedt
2025-07-08  1:26         ` Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 05/18] bpf: introduce bpf_gtramp_link Menglong Dong
2025-07-04  7:00   ` kernel test robot
2025-07-04  7:52   ` kernel test robot
2025-07-03 12:15 ` [PATCH bpf-next v2 06/18] bpf: tracing: add support to record and check the accessed args Menglong Dong
2025-07-14 22:07   ` Andrii Nakryiko
2025-07-14 23:45     ` Menglong Dong
2025-07-15 17:11       ` Andrii Nakryiko
2025-07-16 12:50         ` Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 07/18] bpf: refactor the modules_array to ptr_array Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 08/18] bpf: verifier: add btf to the function args of bpf_check_attach_target Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 09/18] bpf: verifier: move btf_id_deny to bpf_check_attach_target Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 10/18] x86,bpf: factor out arch_bpf_get_regs_nr Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 11/18] bpf: tracing: add multi-link support Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 12/18] libbpf: don't free btf if tracing_multi progs existing Menglong Dong
2025-07-14 22:07   ` Andrii Nakryiko
2025-07-15  1:15     ` Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 13/18] libbpf: support tracing_multi Menglong Dong
2025-07-14 22:07   ` Andrii Nakryiko
2025-07-15  1:58     ` Menglong Dong
2025-07-15 17:20       ` Andrii Nakryiko
2025-07-16 12:43         ` Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 14/18] libbpf: add btf type hash lookup support Menglong Dong
2025-07-14 22:07   ` Andrii Nakryiko
2025-07-15  4:40     ` Menglong Dong
2025-07-15 17:20       ` Andrii Nakryiko
2025-07-16 11:53         ` Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 15/18] libbpf: add skip_invalid and attach_tracing for tracing_multi Menglong Dong
2025-07-14 22:07   ` Andrii Nakryiko
2025-07-15  5:48     ` Menglong Dong
2025-07-15 17:23       ` Andrii Nakryiko
2025-07-16 11:46         ` Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 16/18] selftests/bpf: move get_ksyms and get_addrs to trace_helpers.c Menglong Dong
2025-07-03 12:15 ` [PATCH bpf-next v2 17/18] selftests/bpf: add basic testcases for tracing_multi Menglong Dong
2025-07-08 20:07   ` Alexei Starovoitov
2025-07-09  1:33     ` Menglong Dong
2025-07-14 23:49     ` Ihor Solodrai
2025-07-16  0:26       ` Ihor Solodrai
2025-07-16  0:31         ` Alexei Starovoitov
2025-07-16  0:34           ` Ihor Solodrai [this message]
2025-07-03 12:15 ` [PATCH bpf-next v2 18/18] selftests/bpf: add bench tests " Menglong Dong
2025-07-04  8:47 ` [PATCH bpf-next v2 00/18] bpf: tracing multi-link support Jiri Olsa
2025-07-04  8:52   ` Menglong Dong
2025-07-04  8:58     ` Menglong Dong
2025-07-04  9:12       ` Jiri Olsa
2025-07-15  2:31 ` Alexei Starovoitov
2025-07-15  2:44   ` Menglong Dong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b40a13d8-0fc9-44bd-a0c7-e656d0a14819@linux.dev \
    --to=ihor.solodrai@linux.dev \
    --cc=acme@kernel.org \
    --cc=alan.maguire@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=menglong8.dong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.