linux-kernel - Re: [PATCH 2/2] testing/selftests/mm: add soft-dirty merge self-test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5c1ef450-c9ba-4249-9eda-b38efbd76c3f@kernel.org>
Date: Mon, 17 Nov 2025 15:44:46 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
 Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
 Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
 Jann Horn <jannh@...gle.com>, Pedro Falcato <pfalcato@...e.de>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] testing/selftests/mm: add soft-dirty merge self-test

On 14.11.25 18:53, Lorenzo Stoakes wrote:
> Assert that we correctly merge VMAs containing VM_SOFTDIRTY flags now that
> we correctly handle these as sticky.
> 
> In order to do so, we have to account for the fact the pagemap interface
> checks soft dirty PTEs and additionally that newly merged VMAs are marked
> VM_SOFTDIRTY.
> 
> To account for this we use unfaulted anon VMAs, mapping one VMA in and
> clearing soft-dirty, then another separate from the first which will be
> marked soft-dirty which we then mremap() into place.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> ---
>   tools/testing/selftests/mm/soft-dirty.c | 51 ++++++++++++++++++++++++-
>   1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/mm/soft-dirty.c b/tools/testing/selftests/mm/soft-dirty.c
> index 4ee4db3750c1..bb29edb1e2a3 100644
> --- a/tools/testing/selftests/mm/soft-dirty.c
> +++ b/tools/testing/selftests/mm/soft-dirty.c
> @@ -184,6 +184,54 @@ static void test_mprotect(int pagemap_fd, int pagesize, bool anon)
>   		close(test_fd);
>   }
>   
> +static void test_merge(int pagemap_fd, int pagesize)
> +{
> +	char *reserved, *map, *map2;
> +
> +	/* Reserve space. */

It took me a while to figure out why you are using 4 pages. I guess you 
want to make sure that we don't end up merging to the left (or the 
right). A diagram would have helped me.

> +	reserved = mmap(NULL, 4 * pagesize, PROT_NONE,
> +			MAP_ANON | MAP_PRIVATE, -1, 0);
> +	if (reserved == MAP_FAILED)
> +		ksft_exit_fail_msg("mmap failed\n");
> +	munmap(reserved, 4 * pagesize);
> +
> +	/* Map a page. */

Note that we are not actually "mapping a page". "Create a new page-sized 
VMA" or sth like that.

> +	map = mmap(&reserved[pagesize], pagesize, PROT_READ | PROT_WRITE,
> +		   MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> +	if (map == MAP_FAILED)
> +		ksft_exit_fail_msg("mmap failed\n");
> +
> +	/* This will clear VM_SOFTDIRTY too. */
> +	clear_softdirty();
> +
> +	/*
> +	 * Now place a new mapping which will be marked VM_SOFTDIRTY. Away from
> +	 * map.

Could we have something "to the right" of this new VMA that we might be 
merging with (that might interfere?) and if so, do we care?

Just wondering if we would actually want a reserved area that spans 5 
page sizes to rule out these cases.

mmap1

[ empty ][ VMA1  ][ empty                   ]

mmap2

[ empty ][ VMA1  ][ empty ][ VMA2  ][ empty ]

mremap

[ empty ][ VMA1  ][ VMA2  ][ empty          ]

which is after the merge

[ empty ][ VMA (SD)       ][                ]

-- 
Cheers

David