Re: [PATCH v2 bpf-next 10/10] selftests/bpf: add build ID tests

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

On Thu, Jul 25, 2024 at 5:12 AM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Wed, Jul 24, 2024 at 03:52:10PM -0700, Andrii Nakryiko wrote:
> > Add a new set of tests validating behavior of capturing stack traces
> > with build ID. We extend uprobe_multi target binary with ability to
> > trigger uprobe (so that we can capture stack traces from it), but also
> > we allow to force build ID data to be either resident or non-resident in
> > memory (see also a comment about quirks of MADV_PAGEOUT).
> >
> > That way we can validate that in non-sleepable context we won't get
> > build ID (as expected), but with sleepable uprobes we will get that
> > build ID regardless of it being physically present in memory.
> >
> > Also, we add a small add-on linker script which reorders
> > .note.gnu.build-id section and puts it after (big) .text section,
> > putting build ID data outside of the very first page of ELF file. This
> > will test all the relaxations we did in build ID parsing logic in kernel
> > thanks to freader abstraction.
> >
> > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
>
> one of my bpf selftests runs showed:
>
> test_build_id:PASS:parse_build_id 0 nsec
> subtest_nofault:PASS:skel_open 0 nsec
> subtest_nofault:PASS:link 0 nsec
> subtest_nofault:PASS:trigger_uprobe 0 nsec
> subtest_nofault:PASS:res 0 nsec
> subtest_nofault:FAIL:build_id_status unexpected build_id_status: actual 1 != expected 2
> #42/1    build_id/nofault-paged-out:FAIL
> #42/2    build_id/nofault-paged-in:OK
> #42/3    build_id/sleepable:OK
> #42      build_id:FAIL
>
> I could never reproduce again.. but I wonder the the page could sneak
> in before the bpf program is hit and the buildid will get parsed?
>

Yes, and I just realized that I forgot to mark this test as serial. If
there is parallel test that also runs uprobe_multi and that causes
build_id page to be paged in into page cache, then this might succeed.
So I need to mark the test itself serial.

Another issue which I was debugging (and fixed) yesterday was that if
the memory passed for MADV_PAGEOUT is not yet memory mapped into the
current process, then it won't be really removed from the page cache.
I avoid that by first paging it in, and then MADV_PAGEOUT.


> or maybe likely madvise might just ignore that:
>
>        MADV_PAGEOUT (since Linux 5.4)
>               Reclaim a given range of pages.  This is done to free up memory occupied by these pages.  If a page is anonymous, it will be swapped out.  If
>               a  page  is  file-backed  and dirty, it will be written back to the backing storage.  The advice might be ignored for some pages in the range
>               when it is not applicable.
>
> jirka
>
>
> > ---
> >  tools/testing/selftests/bpf/Makefile          |   5 +-
> >  .../selftests/bpf/prog_tests/build_id.c       | 118 ++++++++++++++++++
> >  .../selftests/bpf/progs/test_build_id.c       |  31 +++++
> >  tools/testing/selftests/bpf/uprobe_multi.c    |  41 ++++++
> >  tools/testing/selftests/bpf/uprobe_multi.ld   |  11 ++
> >  5 files changed, 204 insertions(+), 2 deletions(-)
> >  create mode 100644 tools/testing/selftests/bpf/prog_tests/build_id.c
> >  create mode 100644 tools/testing/selftests/bpf/progs/test_build_id.c
> >  create mode 100644 tools/testing/selftests/bpf/uprobe_multi.ld
> >

[...]