On 6/2/26 10:51 AM, Jerome Marchand wrote: > On 02/06/2026 11:26, Shung-Hsi Yu wrote: >> On Tue, Apr 21, 2026 at 07:59:08AM +0200, Jerome Marchand wrote: >>> On 4/20/26 6:52 PM, Mykyta Yatsenko wrote: >>>> On 4/20/26 2:46 PM, Jerome Marchand wrote: >>>>> The file_reader/on_open_expect_fault fails consistently on my system. >>>>> It expects a page fault on first dynptr read of some range the exe >>>>> file of the current process because it has paged out that page range >>>>> earlier. However a lot can happen to that range (which depending on >>>>> the actual memory layout could contain text section, data section, >>>>> sections )related to dynamic linking...) between the moment it was >>>>> paged out and the moment the bpf program expected to hit a pagefault >>>>> actually run. >>>>> >>>>> A bit of instrumentation with mincore() shows that pages from that >>>>> range were accessed several times before the program is run. In >>>>> particular the call of file_reader__load() seems to fault all the >>>>> range in. >>>>> >>>>> Move the call to madvise(MADV_PAGEOUT) to just before attaching the >>>>> program to minimize the risk of having those page pulled back in from >>>>> under our feet. >>>>> >>>>> Signed-off-by: Jerome Marchand <[email protected]> >>>>> --- >>>> >>>> Thank you for the patch, the change looks good. Does it fail >>>> consistently on 4K page size? >>> >>> It did when I ran the test manually. On our automated testing system, it >>> failed intermittently. >> >> On my fork of BPF CI the test was failing[1] consistently, even when >> this commit is applied. However I wasn't able to reproduce locally on my >> laptop when I ran manually. >> >> Any hints regarding where to look and how to reproduce? > > To investigate the failure I witnessed I instrumented the test with some > calls to mincore(). You can do that to see whether madvise(PAGEOUT) didn't > successfully paged out those pages, or if they were paged back in by the MM > subsystem. I'm afraid that this test isn't very robust: the MM subsystem is > the one that ultimately decides which pages are in or out and it might not > work in the way that this test assumes. >
thanks for the reports, this test is indeed flaky. I'll take a look if it's possible to fix it, or we should just delete it. > Thanks, > Jerome > >> >> Thanks, >> Shung-Hsi >> >> 1: >> https://github.com/shunghsiyu/libbpf/actions/runs/26807198259/job/79027625188 >> >> ... >> >
