Re: [PATCH v3] selftests/mm: add folio_split() and filemap_get_entry() race test

[Zi Yan]

On 19 Mar 2026, at 22:41, Andrew Morton wrote:

> On Thu, 19 Mar 2026 15:04:08 -0400 Zi Yan <ziy@xxxxxxxxxx> wrote:
>
>> The added folio_split_race_test is a modified C port of the race condition
>> test from [1]. The test creates shmem huge pages, where the main thread
>> punches holes in the shmem to cause folio_split() in the kernel and
>> a set of 16 threads reads the shmem to cause filemap_get_entry() in the
>> kernel. filemap_get_entry() reads the folio and xarray split by
>> folio_split() locklessly. The original test[2] is written in rust and uses
>> memfd (shmem backed). This C port uses shmem directly and use a single
>> process.
>>
>> Note: the initial rust to C conversion is done by Cursor.
>
> Sashiko has questions:
> 	https://sashiko.dev/#/patchset/20260319190409.294523-1-ziy%40nvidia.com
>
> (this is getting painful :(.  I hope they're worthwhile)

Q1: Does this test actually trigger filemap_get_entry() in the kernel?

Yes, when MADV_REMOVE triggers folio_split(), in remap_page(), after-split
folios are not mapped. So subsequent accesses to these folios will trigger
page fault and filemap_get_entry().

Q2: Does this loop advance the index further than intended?

Will fix it.

Q3: Is it safe to call thp_restore_settings() from a signal handler?

There is a theoretical hazard but it is unlikely to happen in practice,
since it would only occur when thp_restore_settings() errors out to
use printf().

Q4: Use %zu for uint64_t.

Will use %" PRIu64 " instead.

Best Regards,
Yan, Zi