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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 25, 2024 at 01:03:55PM -0700, Andrii Nakryiko wrote:
> On Thu, Jul 25, 2024 at 5:12 AM Jiri Olsa <olsajiri@xxxxxxxxx> 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@xxxxxxxxxx>
> >
> > 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.

ok, I triggered that in serial run, so I probably hit this one

jirka

> 
> 
> > 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
> > >
> 
> [...]




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux