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 for Android: free password hash cracker in your pocket

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

Message-ID: <c5c31abd-98ee-4f10-8990-0f935035b3c3@lucifer.local>
Date: Mon, 17 Nov 2025 15:15:39 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        "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 Mon, Nov 17, 2025 at 03:44:46PM +0100, David Hildenbrand (Red Hat) wrote:
> 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.

I have spoiled everybody too much with my ASCII diagrams ;)

But _just for you_ I will make one again ;))

>
> > +	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.

Lol depends on your definition I suppose. Not in the sense of page table
mappings. I guess this is fairly redundant anyway so can dorp

>
> > +	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.
>

You're right! This is an oversight, will fix.

> mmap1
>
> [ empty ][ VMA1  ][ empty                   ]
>
> mmap2
>
> [ empty ][ VMA1  ][ empty ][ VMA2  ][ empty ]
>
> mremap
>
> [ empty ][ VMA1  ][ VMA2  ][ empty          ]
>
> which is after the merge
>
> [ empty ][ VMA (SD)       ][                ]

Yeah this is the purpose of adding space around.

I also want to add an additional test anyway so can do both things at once
:)

>
>
> --
> Cheers
>
> David

Cheers, Lorenzo