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
