Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: Jerome Marchand <jmarchan@redhat.com>,
	Shung-Hsi Yu <shung-hsi.yu@suse.com>
Cc: bpf@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
	Mykyta Yatsenko <yatsenko@meta.com>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/bpf: Page out as late a possible in file_reader
Date: Tue, 2 Jun 2026 14:30:23 +0100	[thread overview]
Message-ID: <be8c41c9-17c7-4e1c-87f0-9036b0de4b58@gmail.com> (raw)
In-Reply-To: <939aae44-5901-4f2d-99c8-ad9bd5173f0f@redhat.com>

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 <jmarchan@redhat.com>
>>>>> ---
>>>>
>>>> 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
>>
>> ...
>>
> 


  reply	other threads:[~2026-06-02 13:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 13:46 [PATCH] selftests/bpf: Page out as late a possible in file_reader Jerome Marchand
2026-04-20 16:52 ` Mykyta Yatsenko
2026-04-21  5:59   ` Jerome Marchand
2026-06-02  9:26     ` Shung-Hsi Yu
2026-06-02  9:51       ` Jerome Marchand
2026-06-02 13:30         ` Mykyta Yatsenko [this message]
2026-04-21 10:52 ` Jiri Olsa
2026-04-22 21:20 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be8c41c9-17c7-4e1c-87f0-9036b0de4b58@gmail.com \
    --to=mykyta.yatsenko5@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=jmarchan@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=shuah@kernel.org \
    --cc=shung-hsi.yu@suse.com \
    --cc=song@kernel.org \
    --cc=yatsenko@meta.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox