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. > > 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? > > [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
