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 6895A32D431 for ; Mon, 17 Nov 2025 12:58:29 +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=1763384309; cv=none; b=VtIINi4HrgULmSr/ymaqeASXdaxi00wb2HofKzrRA6NsBQEZIR5OiWjXVqa/Cq9/Ig5X9a1F1o798yImSW+4yl5l2ZJThKSMTEvb4qu3vzKuUeZnVa+85rWt1ptXXcJhrnSPKmnym/Pi9yQQvycvlS09bacxBUhaN8Mv0XYtrS8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763384309; c=relaxed/simple; bh=OLr27sQ+JriRX4/NEDgdTqE74P+APe5Bc1JBLjDHgq4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=C1984ViIqvYc8SY/s4MTFuYaTBfCOw8z9ABNXcwjNdxuCSklhfT58cWYMgF2q1cz53E8B2UnLI1+sUHuBs7GmqmLywduNXeydrvYIP4pJMo/WG+HHcNHqv5aCVDykeFvyEQgk86j6yraDpv72MB+e8+o6ePs73FnofifgGOYu5M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Uhgn3cJv; 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="Uhgn3cJv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FCDFC116B1; Mon, 17 Nov 2025 12:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763384308; bh=OLr27sQ+JriRX4/NEDgdTqE74P+APe5Bc1JBLjDHgq4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Uhgn3cJv5PiL0Ru44n2U1aAWvA4gQuK/A4zSlD33Ju9WdIDaoc4NQCi9BKrydme5U 0YQBymY5uU72yIUqIBCKC9O0IAOn16lO+ukjanViFoKEcpRGZ5DGGV/SECz0RDBUjT rEePn1ib158MU2B6hox8YN6Z8CnVFAAf8bezetMjZXueWirN4xVewvtZ+kdgV6ddMx uIoJDwlqHCfLvfu0d9jdPXE2270dPM93g75FBKwB/rO/CP0Htlee1sS5JKudJbH7wT JgsPZF2O2DkT1Ds6IAJR6fZ2bFZn6G3we5pytq8XbrqcFpBImUoIntYOUfVxzmLaao euff+N0en5yAw== Message-ID: <6020005e-8b62-415f-993e-b1d99e0c5158@kernel.org> Date: Mon, 17 Nov 2025 13:58:19 +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] fixup: mm/rmap: extend rmap and migration support device-private entries To: Balbir Singh , linux-kernel@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org Cc: Andrew Morton , Zi Yan , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Oscar Salvador , Lorenzo Stoakes , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lyude Paul , Danilo Krummrich , David Airlie , Simona Vetter , Ralph Campbell , =?UTF-8?Q?Mika_Penttil=C3=A4?= , Matthew Brost , Francois Dugast References: <20251115002835.3515194-1-balbirs@nvidia.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251115002835.3515194-1-balbirs@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 15.11.25 01:28, Balbir Singh wrote: > Follow the pattern used in remove_migration_pte() in > remove_migration_pmd(). Process the migration entries and if the entry > type is device private, override the pmde with a device private entry > and set the soft dirty and uffd_wp bits with the pmd_swp_mksoft_dirty > and pmd_swp_mkuffd_wp > > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Zi Yan > Cc: Joshua Hahn > Cc: Rakie Kim > Cc: Byungchul Park > Cc: Gregory Price > Cc: Ying Huang > Cc: Alistair Popple > Cc: Oscar Salvador > Cc: Lorenzo Stoakes > Cc: Baolin Wang > Cc: "Liam R. Howlett" > Cc: Nico Pache > Cc: Ryan Roberts > Cc: Dev Jain > Cc: Barry Song > Cc: Lyude Paul > Cc: Danilo Krummrich > Cc: David Airlie > Cc: Simona Vetter > Cc: Ralph Campbell > Cc: Mika Penttilä > Cc: Matthew Brost > Cc: Francois Dugast > > Signed-off-by: Balbir Singh > --- > This fixup should be squashed into the patch "mm/rmap: extend rmap and > migration support" of mm/mm-unstable > > mm/huge_memory.c | 27 +++++++++++++++++---------- > 1 file changed, 17 insertions(+), 10 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 9dda8c48daca..50ba458efcab 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -4698,16 +4698,6 @@ void remove_migration_pmd(struct page_vma_mapped_walk *pvmw, struct page *new) > folio_get(folio); > pmde = folio_mk_pmd(folio, READ_ONCE(vma->vm_page_prot)); > > - if (folio_is_device_private(folio)) { > - if (pmd_write(pmde)) > - entry = make_writable_device_private_entry( > - page_to_pfn(new)); > - else > - entry = make_readable_device_private_entry( > - page_to_pfn(new)); > - pmde = swp_entry_to_pmd(entry); > - } > - > if (pmd_swp_soft_dirty(*pvmw->pmd)) > pmde = pmd_mksoft_dirty(pmde); > if (is_writable_migration_entry(entry)) > @@ -4720,6 +4710,23 @@ void remove_migration_pmd(struct page_vma_mapped_walk *pvmw, struct page *new) > if (folio_test_dirty(folio) && is_migration_entry_dirty(entry)) > pmde = pmd_mkdirty(pmde); > > + if (folio_is_device_private(folio)) { > + swp_entry_t entry; It's a bit nasty to have the same variable shadowed here. We could reuse the existing entry by handling the code more similar to remove_migration_pte(): determine RMAP_EXCLUSIVE earlier. > + > + if (pmd_write(pmde)) > + entry = make_writable_device_private_entry( > + page_to_pfn(new)); > + else > + entry = make_readable_device_private_entry( > + page_to_pfn(new)); > + pmde = swp_entry_to_pmd(entry); > + > + if (pmd_swp_soft_dirty(*pvmw->pmd)) > + pmde = pmd_swp_mksoft_dirty(pmde); > + if (pmd_swp_uffd_wp(*pvmw->pmd)) > + pmde = pmd_swp_mkuffd_wp(pmde); > + } > + > if (folio_test_anon(folio)) { > rmap_t rmap_flags = RMAP_NONE; > I guess at some point we could separate both parts completely (no need to do all this work on pmdb before the folio_is_device_private(folio) check, so this could be if (folio_is_device_private(folio)) { ... } else { entry = pmd_to_swp_entry(*pvmw->pmd); folio_get(folio); ... } That is something for another day though, and remove_migration_pte() should be cleaned up then as well. -- Cheers David