Re: [PATCH v5 bpf-next 09/10] bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers

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

On Mon, Aug 12, 2024 at 6:05 PM Andi Kleen <ak@linux.intel.com> wrote:
>
> On Mon, Aug 12, 2024 at 05:29:31PM -0700, Andrii Nakryiko wrote:
> > Add sleepable implementations of bpf_get_stack() and
> > bpf_get_task_stack() helpers and allow them to be used from sleepable
> > BPF program (e.g., sleepable uprobes).
>
> Is missing the header actually a real problem you saw?

It's hard to quantify this from production data, because there are
multiple possible reasons to fail to get build ID in BPF program. All
of which will result in "no build ID" condition.

But more generally speaking, failure to read some piece of memory from
non-sleepable BPF programs is a real problem for a meaningful
percentage of cases, so being able to do that more reliably in
sleepable context is important.

In this case, given this build ID fetching code is used from
PROCMAP_QUERY ioctl() on top of /proc/<pid>/maps, it's good to have a
guarantee that if underlying file is a proper ELF file with valid
build ID, that API will return it. It allows applications to avoid
overhead of retrying it through other less reliable and more
cumbersome means.

>
> I presume the user tools do have a fallback to read the
> build by themselves if it happens
>

It's all best effort, strictly speaking, but the percentage of
successful cases matters across the entire fleet, so anything that can
be done to improve the success rate is helpful. Retrying is possible,
but comes with extra complications, which are not always acceptable.
E.g., it's just racy (application might exit by the time we retry), or
will require extra privileges (because user space will be accessing
entire ELF file contents), etc.