From: Sarthak Sharma <sarthak.sharma@arm.com>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: akpm@linux-foundation.org, david@kernel.org, liam@infradead.org,
vbabka@suse.com, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, shuah@kernel.org, jhubbard@nvidia.com,
kaleshsingh@google.com, anshuman.khandual@arm.com,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 00/12] selftests/mm: improve mremap_test
Date: Mon, 12 Oct 2026 16:38:47 +0530 [thread overview]
Message-ID: <68905ee7-83b1-4d5f-a1e6-8ddd2ae291d1@arm.com> (raw)
In-Reply-To: <asyxQbp8EfVE9yQs@gremlin>
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
prev parent reply other threads:[~2026-10-12 11:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 9:24 Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 01/12] selftests/mm: mremap_test: remove command line options Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 02/12] selftests/mm: mremap_test: drop munmap() checks from cleanup paths Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 03/12] selftests/mm: mremap_test: simplify errno handling Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 04/12] selftests/mm: mremap_test: use kselftest helpers Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 05/12] selftests/mm: mremap_test: skip test when userfaultfd is unavailable Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 06/12] selftests/mm: mremap_test: fail unexpected mremap successes Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 07/12] selftests/mm: mremap_test: fail on data corruption Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 08/12] selftests/mm: mremap_test: handle cleanup after mmap failures Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 09/12] selftests/mm: mremap_test: remove perf tests and timing Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 10/12] selftests/mm: mremap_test: replace validation threshold with sampled checks Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 11/12] selftests/mm: mremap_test: replace random data with deterministic pattern Sarthak Sharma
2026-10-06 9:25 ` [PATCH v2 12/12] selftests/mm: mremap_test: strengthen multi VMA validation Sarthak Sharma
2026-10-12 4:50 ` [PATCH v2 00/12] selftests/mm: improve mremap_test Sarthak Sharma
2026-10-12 10:13 ` Lorenzo Stoakes (ARM)
2026-10-12 11:08 ` Sarthak Sharma [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68905ee7-83b1-4d5f-a1e6-8ddd2ae291d1@arm.com \
--to=sarthak.sharma@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=david@kernel.org \
--cc=jhubbard@nvidia.com \
--cc=kaleshsingh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®