On Wed, Aug 12, 2020 at 8:27 AM Song Liu <songliubraving@xxxxxx> wrote: > > > > > On Aug 12, 2020, at 5:31 AM, Jiri Olsa <jolsa@xxxxxxxxxx> 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@xxxxxxxxxx> > > LGTM. Thanks for the fix! > > Acked-by: Song Liu <songliubraving@xxxxxx> It's a good fix. Applied to bpf tree. Thanks
