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.

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.

While here, requesting for some feedback on this series, if anyone has
had a chance to look at it :).

[1]
https://sashiko.dev/#/patchset/20261006092511.145776-1-sarthak.sharma%40arm.com

[2] https://lore.kernel.org/linux-mm/agH1ZSdX_7QF8P_I@lucifer/


Reply via email to