Re: [PATCH RESEND 0/9] selftests/mm: improve mremap_test

[Sarthak Sharma]

On 9/24/26 10:30 AM, Sarthak Sharma wrote:
> This series fixes several correctness issues in mremap_test and
> simplifies and strengthens its data validation.
> 
> Patch 1 converts the mremap_test to use kselftest helpers, removes
> manual tracking of failed tests and corrects some spelling errors.
> 
> Patches 2 to 5 fix userfaultfd skipping, unexpected mremap success
> handling, multi-VMA data validation and failure reporting when data
> corruption is detected.
> 
> Patch 6 removes the randomization and uses a simple pattern based approach.
> 
> Patch 7 removes perf tests and timing infrastructure.
> 
> Patch 8 removes validation threshold and always validates complete mappings.
> 
> Patch 9 strengthens the multi VMA validation by also checking the
> mapping state of holes after remapping.

Hello everyone! Just wanted to check if someone has had a chance to look
at the series.

Also, Sashiko has a concern [1], and I had the same while posting the
series. I hope I can get some opinion from the community.

Currently, for PUD remap tests, we allocate a source mapping of 2GB. We
only fault in the first threshold_mb amount of memory, remap the whole
region, and validate the already faulted threshold_mb amount of memory,
which is, by default, equal to 4MB and can be changed by the user by
supplying a command line option.

Since we plan to remove all command line options from teh selftests, I
removed threshold_mb altogether, following some discussion on the list
[2]. This would now cause a 2GB source mapping, and its contents copied
from another 2GB buffer. This causes the process to have a 4GB RSS.
Sashiko says that this can cause OOM killing in small CI machines.

Would it be okay to keep a 4GB RSS in this case, or should we find some
other way of validating a part of the whole range instead?

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

[2]
https://lore.kernel.org/all/2e34b619-085f-4a9c-bb41-bc024fd40dd7@xxxxxxxxxx/