Re: [PATCH v2 00/12] selftests/mm: improve mremap_test

[Sarthak Sharma]

Hi Lorenzo!

On 10/12/26 3:43 PM, Lorenzo Stoakes (ARM) wrote:
> On Mon, Oct 12, 2026 at 10:20:45AM +0530, Sarthak Sharma wrote:
>> On 10/6/26 2:54 PM, Sarthak Sharma wrote:
>>> This series fixes correctness issues in mremap_test, simplifies its
>>> test infrastructure and strengthens validation of remapped mappings.
>>>
>>> Patches 1-3 remove unused command line handling, unnecessary cleanup
>>> checks and redundant errno handling. Patch 4 converts the test to use
>>> kselftest helpers and removes manual failure tracking.
>>>
>>> Patches 5-8 fix handling of unavailable userfaultfd support, unexpected
>>> mremap() successes, data-corruption failures and cleanup after mmap()
>>> failures. Patch 9 removes perf tests and timing infrastructure.
>>>
>>> Patches 10 and 11 replace threshold-based random-data validation with
>>> sampled validation and a deterministic data pattern. Patch 12
>>> strengthens multi VMA validation by also checking the mapping state
>>> of holes after remapping.
>>
>> [...]
>>
>>> ---
>>> Sarthak Sharma (12):
>>>   selftests/mm: mremap_test: remove command line options
>>>   selftests/mm: mremap_test: drop munmap() checks from cleanup paths
>>>   selftests/mm: mremap_test: simplify errno handling
>>>   selftests/mm: mremap_test: use kselftest helpers
>>>   selftests/mm: mremap_test: skip test when userfaultfd is unavailable
>>>   selftests/mm: mremap_test: fail unexpected mremap successes
>>>   selftests/mm: mremap_test: fail on data corruption
>>>   selftests/mm: mremap_test: handle cleanup after mmap failures
>>>   selftests/mm: mremap_test: remove perf tests and timing
>>>   selftests/mm: mremap_test: replace validation threshold with sampled
>>>     checks
>>>   selftests/mm: mremap_test: replace random data with deterministic
>>>     pattern
>>>   selftests/mm: mremap_test: strengthen multi VMA validation
>>>
>>>  tools/testing/selftests/mm/mremap_test.c | 701 ++++++++++-------------
>>>  1 file changed, 291 insertions(+), 410 deletions(-)
>>>
>>
>> I wanted to address the concern Sashiko has over this patch series [1].
>> It says that mremap(..., MAP_FIXED) over a range containing multiple
>> VMAs should unmap the whole range first and then map the VMAs.
> 
> I don't think you need to spend time worrying about sashiko stuff about
> mremap() behaviour in a test series :)

:)

> 
>>
>> But this is not the case, as was discussed on the list earlier as well.
>> We iterate over the VMAs in the range and only unmap and then map the
>> region that the VMAs occupy. IOW, as quoted by Lorenzo [2], "the
>> sematics are such that gaps are not propagated (i.e. it is as if you
>> mremap()'d each individually)". So if we remap over an existing mapping,
>> the mapping region on which a hole is remapped should not be affected at
>> all. So this is a false positive.
> 
> I will be removing the gaps stuff in any case (as discussed elsewhere
> too).
> 
> It's problematic, more so for the fact stuff can get mapped in gaps before
> the mremap() operation.

Yup, makes sense.

> 
>>
>> While here, requesting for some feedback on this series, if anyone has
>> had a chance to look at it :).
> 
> Thanks for the series, this cycle has been very busy so I think this is one
> for the next cycle (i.e. targeting 7.5).
> 
> So I'd recommend resending at 7.4-rc1?

Sure, I'll resend around that time.

> 
>>
>> [1]
>> https://sashiko.dev/#/patchset/20261006092511.145776-1-sarthak.sharma%40arm.com
>>
>> [2] https://lore.kernel.org/linux-mm/agH1ZSdX_7QF8P_I@lucifer/
>>
> 
> --
> Cheers, Lorenzo