From nobody Mon Dec 15 12:45:14 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1F02C76188 for ; Wed, 5 Apr 2023 16:03:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238740AbjDEQDa (ORCPT ); Wed, 5 Apr 2023 12:03:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237503AbjDEQD2 (ORCPT ); Wed, 5 Apr 2023 12:03:28 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA8435BB7 for ; Wed, 5 Apr 2023 09:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680710565; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9SgMl0U05ydcYM0cFwFg6RkUkX/SVGBlhLdBNLErgqU=; b=ZUwcpALrnDcDVCL8viQrg/fVO0rMBki+Oj33nXSdDe5weVBGE78xPM9FrXcMASbqmtlJlW vx90AVrjZ/ba/kQzyNwGziHn7XQdg291n5MbeL9ua6hdDdLov+KZi3yAiqisoo5ULODwgr KFCRPCxw1AmPjOR6mNCYotdcRbMjieA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-167-QqiIz_h_NguASfvv2dusNA-1; Wed, 05 Apr 2023 12:02:40 -0400 X-MC-Unique: QqiIz_h_NguASfvv2dusNA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 27BE238221CD; Wed, 5 Apr 2023 16:02:40 +0000 (UTC) Received: from t480s.fritz.box (unknown [10.39.195.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id DD0DF492C14; Wed, 5 Apr 2023 16:02:38 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , Peter Xu , Muhammad Usama Anjum , stable@vger.kernel.org Subject: [PATCH v2 1/2] mm/userfaultfd: fix uffd-wp handling for THP migration entries Date: Wed, 5 Apr 2023 18:02:35 +0200 Message-Id: <20230405160236.587705-2-david@redhat.com> In-Reply-To: <20230405160236.587705-1-david@redhat.com> References: <20230405160236.587705-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Looks like what we fixed for hugetlb in commit 44f86392bdd1 ("mm/hugetlb: fix uffd-wp handling for migration entries in hugetlb_change_protection()") similarly applies to THP. Setting/clearing uffd-wp on THP migration entries is not implemented properly. Further, while removing migration PMDs considers the uffd-wp bit, inserting migration PMDs does not consider the uffd-wp bit. We have to set/clear independently of the migration entry type in change_huge_pmd() and properly copy the uffd-wp bit in set_pmd_migration_entry(). Verified using a simple reproducer that triggers migration of a THP, that the set_pmd_migration_entry() no longer loses the uffd-wp bit. Fixes: f45ec5ff16a7 ("userfaultfd: wp: support swap and page migration") Reviewed-by: Peter Xu Cc: stable@vger.kernel.org Signed-off-by: David Hildenbrand --- mm/huge_memory.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 032fb0ef9cd1..e3706a2b34b2 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1838,10 +1838,10 @@ int change_huge_pmd(struct mmu_gather *tlb, struct = vm_area_struct *vma, if (is_swap_pmd(*pmd)) { swp_entry_t entry =3D pmd_to_swp_entry(*pmd); struct page *page =3D pfn_swap_entry_to_page(entry); + pmd_t newpmd; =20 VM_BUG_ON(!is_pmd_migration_entry(*pmd)); if (is_writable_migration_entry(entry)) { - pmd_t newpmd; /* * A protection check is difficult so * just be safe and disable write @@ -1855,8 +1855,16 @@ int change_huge_pmd(struct mmu_gather *tlb, struct v= m_area_struct *vma, newpmd =3D pmd_swp_mksoft_dirty(newpmd); if (pmd_swp_uffd_wp(*pmd)) newpmd =3D pmd_swp_mkuffd_wp(newpmd); - set_pmd_at(mm, addr, pmd, newpmd); + } else { + newpmd =3D *pmd; } + + if (uffd_wp) + newpmd =3D pmd_swp_mkuffd_wp(newpmd); + else if (uffd_wp_resolve) + newpmd =3D pmd_swp_clear_uffd_wp(newpmd); + if (!pmd_same(*pmd, newpmd)) + set_pmd_at(mm, addr, pmd, newpmd); goto unlock; } #endif @@ -3251,6 +3259,8 @@ int set_pmd_migration_entry(struct page_vma_mapped_wa= lk *pvmw, pmdswp =3D swp_entry_to_pmd(entry); if (pmd_soft_dirty(pmdval)) pmdswp =3D pmd_swp_mksoft_dirty(pmdswp); + if (pmd_uffd_wp(pmdval)) + pmdswp =3D pmd_swp_mkuffd_wp(pmdswp); set_pmd_at(mm, address, pvmw->pmd, pmdswp); page_remove_rmap(page, vma, true); put_page(page); --=20 2.39.2 From nobody Mon Dec 15 12:45:14 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47928C76188 for ; Wed, 5 Apr 2023 16:03:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232698AbjDEQDl (ORCPT ); Wed, 5 Apr 2023 12:03:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238897AbjDEQDf (ORCPT ); Wed, 5 Apr 2023 12:03:35 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED8995FCF for ; Wed, 5 Apr 2023 09:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680710569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=haUnYelB5LusrEoBxVPl4UNNfNfVynWBkPKVNWIDj2U=; b=Syajd34ab0PjiryPvfcj4ZKv3oHUu7PpgOTG6agSHWbMIlKn/u9uR3pn51uA8hdP6cHdS8 xq7xcaa3yPxJ9TCWPP0eE7OFytGHvJr9zzhgxWjg6LeKD62E/hpmSLziEN+9hJwiEn+kQG 22+bD8NvmEZKD26s+2otOPhngbeFWyU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-643-_hSYB7tFOaKls9fUcmn9jQ-1; Wed, 05 Apr 2023 12:02:42 -0400 X-MC-Unique: _hSYB7tFOaKls9fUcmn9jQ-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1837C1C02D3D; Wed, 5 Apr 2023 16:02:42 +0000 (UTC) Received: from t480s.fritz.box (unknown [10.39.195.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8AEDF492C14; Wed, 5 Apr 2023 16:02:40 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , Peter Xu , Muhammad Usama Anjum Subject: [PATCH v2 2/2] mm/userfaultfd: don't consider uffd-wp bit of writable migration entries Date: Wed, 5 Apr 2023 18:02:36 +0200 Message-Id: <20230405160236.587705-3-david@redhat.com> In-Reply-To: <20230405160236.587705-1-david@redhat.com> References: <20230405160236.587705-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" If we end up with a writable migration entry that has the uffd-wp bit set, we already messed up: the source PTE/PMD was writable, which means we could have modified the page without notifying uffd first. Setting the uffd-wp bit always implies converting migration entries to !writable migration entries. Commit 8f34f1eac382 ("mm/userfaultfd: fix uffd-wp special cases for fork()") documents that "3. Forget to carry over uffd-wp bit for a write migration huge pmd entry", but it doesn't really say why that should be relevant. So let's remove that code to avoid hiding an eventual underlying issue (in the future, we might want to warn when creating writable migration entries that have the uffd-wp bit set -- or even better when turning a PTE writable that still has the uffd-wp bit set). This now matches the handling for hugetlb migration entries in hugetlb_change_protection(). In copy_huge_pmd()/copy_nonpresent_pte()/copy_hugetlb_page_range(), we still transfer the uffd-bit also for writable migration entries, but simply because we have unified handling for "writable" and "readable-exclusive" migration entries, and we care about transferring the uffd-wp bit for the latter. Reviewed-by: Peter Xu Signed-off-by: David Hildenbrand --- mm/huge_memory.c | 2 -- mm/mprotect.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index e3706a2b34b2..fffc953fa6ea 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1853,8 +1853,6 @@ int change_huge_pmd(struct mmu_gather *tlb, struct vm= _area_struct *vma, newpmd =3D swp_entry_to_pmd(entry); if (pmd_swp_soft_dirty(*pmd)) newpmd =3D pmd_swp_mksoft_dirty(newpmd); - if (pmd_swp_uffd_wp(*pmd)) - newpmd =3D pmd_swp_mkuffd_wp(newpmd); } else { newpmd =3D *pmd; } diff --git a/mm/mprotect.c b/mm/mprotect.c index 13e84d8c0797..e04e9ea62ae7 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -223,8 +223,6 @@ static long change_pte_range(struct mmu_gather *tlb, newpte =3D swp_entry_to_pte(entry); if (pte_swp_soft_dirty(oldpte)) newpte =3D pte_swp_mksoft_dirty(newpte); - if (pte_swp_uffd_wp(oldpte)) - newpte =3D pte_swp_mkuffd_wp(newpte); } else if (is_writable_device_private_entry(entry)) { /* * We do not preserve soft-dirtiness. See --=20 2.39.2