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