[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5238E896-6A88-4857-B8D4-3C2E8C4E9F2C@fb.com>
Date: Wed, 12 Aug 2020 15:26:43 +0000
From: Song Liu <songliubraving@...com>
To: Jiri Olsa <jolsa@...nel.org>
CC: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
Martin Lau <kafai@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>
Subject: Re: [RFC PATCH bpf-next] bpf: Iterate through all PT_NOTE sections
when looking for build id
> On Aug 12, 2020, at 5:31 AM, Jiri Olsa <jolsa@...nel.org> wrote:
>
> Currently when we look for build id within bpf_get_stackid helper
> call, we check the first NOTE section and we fail if build id is
> not there.
>
> However on some system (Fedora) there can be multiple NOTE sections
> in binaries and build id data is not always the first one, like:
>
> $ readelf -a /usr/bin/ls
> ...
> [ 2] .note.gnu.propert NOTE 0000000000000338 00000338
> 0000000000000020 0000000000000000 A 0 0 8358
> [ 3] .note.gnu.build-i NOTE 0000000000000358 00000358
> 0000000000000024 0000000000000000 A 0 0 437c
> [ 4] .note.ABI-tag NOTE 000000000000037c 0000037c
> ...
>
> So the stack_map_get_build_id function will fail on build id retrieval
> and fallback to BPF_STACK_BUILD_ID_IP.
>
> This patch is changing the stack_map_get_build_id code to iterate
> through all the NOTE sections and try to get build id data from
> each of them.
>
> When tracing on sched_switch tracepoint that does bpf_get_stackid
> helper call kernel build, I can see about 60% increase of successful
> build id retrieval. The rest seems fails on -EFAULT.
>
> Signed-off-by: Jiri Olsa <jolsa@...nel.org>
LGTM. Thanks for the fix!
Acked-by: Song Liu <songliubraving@...com>
Powered by blists - more mailing lists