Re: [PATCHv4 bpf-next 2/4] bpf: Add bpf_vma_build_id_parse function and kfunc

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Tue, Nov 29, 2022 at 5:27 PM Hao Luo <haoluo@google.com> wrote:
>
> On Tue, Nov 29, 2022 at 4:35 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> > This is hardly a generic solution, as it requires instrumenting every
> > application to do this, right? So what I'm proposing is exactly to
> > avoid having each individual application do something special just to
> > allow profiling tools to capture build_id.
>
> I agree. Because the mlock approach is working, we didn't look further
> or try improving it. But an upstreamable and generic solution would be
> nice. I think Jiri has started looking at it, I am happy to help
> there.
>

Ok, cool, it would be great to have this work reliably and not rely on
user-space apps doing something special here.

> > Is this due to remapping some binary onto huge pages?
>
> I think so, but I'm not sure.
>

We used to have this problem, but then Song added some in-kernel
support that we now preserve the original file information. Song, do
you mind providing details?

> > But regardless, your custom BPF applications can fetch this build_id
> > from vm_area_struct->anon_name in pure BPF code, can't it? Why do you
> > need to modify in-kernel build_id_parse implementation?
>
> The user is using bpf_get_stack() to collect stack traces. They don't
> implement walking the stack and fetching build_id from vma in their
> BPF code.

Ah, I see. Let's figure out why Song's approach doesn't work in your
case, because this anon_name hack is just that -- hack.