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

[David Hildenbrand (Red Hat)]

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@xxxxxxxxxx>
> ---
>   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