From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 6/6] tools/testing/selftests/mm: add MAP_PRIVATE-/dev/zero merge tests
Date: Mon, 7 Sep 2026 19:08:48 +0200 [thread overview]
Message-ID: <42c1b1be-d176-45fd-b467-464b5b87e116@kernel.org> (raw)
In-Reply-To: <20260902-map-private-dev-zero-v1-6-a578c730cec7@kernel.org>
On 9/2/26 20:00, Lorenzo Stoakes (ARM) wrote:
> Assert that MAP_PRIVATE-mapped /dev/zero mappings behave like they are
> anonymous.
>
> We test both unfaulted and faulted/unfaulted merges - each with the regions
> having page offset of 0, which would not merge if the mappings were treated
> as if they were file-backed.
>
> With the recent change that makes them behave as pure anonymous mappings,
> the merges should succeed as their page offsets are equal to their
> anonymous page offsets.
>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> tools/testing/selftests/mm/merge.c | 104 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 104 insertions(+)
>
> diff --git a/tools/testing/selftests/mm/merge.c b/tools/testing/selftests/mm/merge.c
> index 52b8727b6628..7c528d470404 100644
> --- a/tools/testing/selftests/mm/merge.c
> +++ b/tools/testing/selftests/mm/merge.c
> @@ -1362,6 +1362,110 @@ TEST_F(merge, anon_and_page_offset_mismatch_memfd)
> ASSERT_EQ(procmap->query.vma_end, (unsigned long)ptr + 5 * page_size);
> }
>
> +TEST_F(merge, merge_map_private_dev_zero_unfaulted)
> +{
> + struct procmap_fd *procmap = &self->procmap;
> + unsigned int page_size = self->page_size;
> + char *carveout = self->carveout;
> + char *ptr, *ptr2;
> + int fd_zero;
> +
> + if (access("/dev/zero", F_OK))
> + SKIP(return, "No /dev/zero.");
> + fd_zero = open("/dev/zero", O_RDWR);
> + ASSERT_NE(fd_zero, -1);
> +
> + /*
> + * Map two MAP_PRIVATE-/dev/zero VMAs next to one another with offset 0
> + * each.
> + *
> + * With these being made truly anonymous upon mapping, they will
> + * merge. If they were file-backed VMAs the page offsets would prevent
> + * merge:
Nit: "the" merge? You're the native speaker, so I don't know if what you have is
just correct :)
> + *
> + * |-----||------| |-------------|
> + * | ptr || ptr2 | -> | ptr |
> + * |-----||------| |-------------|
> + */
> + ptr = mmap(carveout, 5 * page_size, PROT_READ | PROT_WRITE,
> + MAP_FIXED | MAP_PRIVATE, fd_zero, 0);
> + if (ptr == MAP_FAILED) {
> + close(fd_zero);
> + ASSERT_TRUE(false);
> + }
> + ptr2 = mmap(&carveout[5 * page_size], 5 * page_size,
> + PROT_READ | PROT_WRITE, MAP_FIXED | MAP_PRIVATE, fd_zero, 0);
> + if (ptr2 == MAP_FAILED) {
> + close(fd_zero);
Is the close() really required before the ASSERT? After all, you're also not
munmap'ing, so I wonder to which degree we have to clean up.
So maybe this could just become a
ASSERT_NE(ptr2, MAP_FAILED);
Same for ptr above.
You could likely also do
ptr = mmap()
ptr2 = mmap()
close(fd_zero);
ASSERT_NE(ptr, MAP_FAILED);
ASSERT_NE(ptr2, MAP_FAILED);
> + ASSERT_TRUE(false);
> + }
> + close(fd_zero);
> +
> + /* Assert that they merged. */
> + ASSERT_TRUE(find_vma_procmap(procmap, ptr));
> + ASSERT_EQ(procmap->query.vma_start, (unsigned long)ptr);
> + ASSERT_EQ(procmap->query.vma_end, (unsigned long)ptr + 10 * page_size);
> +}
> +
> +TEST_F(merge, merge_map_private_dev_zero_faulted_unfaulted)
> +{
> + struct procmap_fd *procmap = &self->procmap;
> + unsigned int page_size = self->page_size;
> + char *carveout = self->carveout;
> + char *ptr, *ptr2;
> + int fd_zero;
> +
> + if (access("/dev/zero", F_OK))
> + SKIP(return, "No /dev/zero.");
> + fd_zero = open("/dev/zero", O_RDWR);
> + ASSERT_NE(fd_zero, -1);
> +
> + /*
> + * Map a MAP_PRIVATE mapping of /dev/zero with page offset 0, then fault
> + * it in:
> + *
> + * |-------------------------------|
> + * | faulted |
> + * |-------------------------------|
> + */
> + ptr = mmap(carveout, 15 * page_size, PROT_READ | PROT_WRITE,
> + MAP_FIXED | MAP_PRIVATE, fd_zero, 0);
> + if (ptr == MAP_FAILED) {
> + close(fd_zero);
> + ASSERT_TRUE(false);
Same question regarding cleanup requirements. The ASSERT_TRUE(false) looks a bit
odd.
--
Cheers,
David
next prev parent reply other threads:[~2026-09-07 17:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 18:00 [PATCH 0/6] mm: make MAP_PRIVATE-/dev/zero mappings truly anonymous Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 1/6] mm: move drivers/char/mem.c to mm/char-mem.c Lorenzo Stoakes (ARM)
2026-09-03 12:34 ` Mike Rapoport
2026-09-07 16:20 ` David Hildenbrand (Arm)
2026-09-02 18:00 ` [PATCH 2/6] mm: implement file_is_dev_zero() to uniquely identify /dev/zero Lorenzo Stoakes (ARM)
2026-09-07 16:21 ` David Hildenbrand (Arm)
2026-09-07 16:29 ` Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 3/6] mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous Lorenzo Stoakes (ARM)
2026-09-07 16:04 ` Gregory Price
2026-09-07 16:26 ` Lorenzo Stoakes (ARM)
2026-09-07 16:56 ` David Hildenbrand (Arm)
2026-09-07 17:38 ` Lorenzo Stoakes (ARM)
2026-09-07 19:54 ` David Hildenbrand (Arm)
2026-09-08 8:46 ` Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 4/6] mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 5/6] tools/testing/vma: add test to assert MAP_PRIVATE-/dev/zero is anon Lorenzo Stoakes (ARM)
2026-09-02 18:00 ` [PATCH 6/6] tools/testing/selftests/mm: add MAP_PRIVATE-/dev/zero merge tests Lorenzo Stoakes (ARM)
2026-09-07 17:08 ` David Hildenbrand (Arm) [this message]
2026-09-08 8:56 ` Lorenzo Stoakes (ARM)
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=42c1b1be-d176-45fd-b467-464b5b87e116@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=baolin.wang@linux.alibaba.com \
--cc=gregkh@linuxfoundation.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.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=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.