From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E235332BF31 for ; Mon, 17 Nov 2025 14:44:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763390692; cv=none; b=HN7wVRdaOJIE2qQcujvoXIbhoEc/VtJfIkXipZIKc/hvA9EPNQmIvSWmGKVVqSX8vDL5WvrsqoVwzC4xlsVjbfItcVd/czt2E4nkbmItEApR09gboAPbGyBe/Dr+8r277dLioAEUVhYWZXD9m1QsbeVC9HxL9VVWUZsTvLh69+o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763390692; c=relaxed/simple; bh=CDUtGC8M3JhLCirSaVnhUZ14GDqNgW28PRsDMxMIwN8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qVMCpWn+unNNAQrRVJuT9bzWPuIE/j1Eeqc+rVFM3kfh6uK+TBA0mRmU06pkUDoPHI433LbsxHjdgMI+kjWpo93W2+e/Egf6k6tzvfbt+vdyMI+fZwYqww7k3DoxHDeIHd9JoA2lYCfmDpAxCGHdyeoRdq2c0U4F2PQ+ihr6SBI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GbuqeJmr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GbuqeJmr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4BD7C2BC86; Mon, 17 Nov 2025 14:44:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763390691; bh=CDUtGC8M3JhLCirSaVnhUZ14GDqNgW28PRsDMxMIwN8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=GbuqeJmr+d0qjBmWyK7SfOecXabTSFpyEsvxZVRZ8SgY5E+bxn0dIeEBYKhmxgNUV Khzs5ypJk32Js0UscaSIe7+gH3euRck3254HrKRxw9eHjaYdVPLNFPafHzoVksPp5v N6U4JaeDipclwUWBJkxZcICZN7Edj1zH7RH5YhjjP7KKT19SHXwyl1XEN7bm3RIM+t b5Z/akwW6FwdsYYIU6gX4VI2LshtqxScQfsNeLWouGpM0P/nDUflB4BrUEs51DCyr1 KGX/uAUs92bYJvYGooygqEQ5eosSWxOsuuSdgT6Lg8WZ6SHNWN3kVdoLiXsxrXijss 7mlxIiUhKsP9A== Message-ID: <5c1ef450-c9ba-4249-9eda-b38efbd76c3f@kernel.org> Date: Mon, 17 Nov 2025 15:44:46 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] testing/selftests/mm: add soft-dirty merge self-test To: Lorenzo Stoakes , Andrew Morton Cc: "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <0db6aeb73d42876756ba73163cc0cc6e7e8c6100.1763142412.git.lorenzo.stoakes@oracle.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <0db6aeb73d42876756ba73163cc0cc6e7e8c6100.1763142412.git.lorenzo.stoakes@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > --- > 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