From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Xu <peterx@redhat.com>,
Muhammad Usama Anjum <usama.anjum@collabora.com>
Subject: [PATCH v1 2/2] mm/userfaultfd: don't consider uffd-wp bit of writable migration entries
Date: Wed, 5 Apr 2023 16:25:35 +0200 [thread overview]
Message-ID: <20230405142535.493854-3-david@redhat.com> (raw)
In-Reply-To: <20230405142535.493854-1-david@redhat.com>
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.
Signed-off-by: David Hildenbrand <david@redhat.com>
---
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 bdda4f426d58..f977c965fdad 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 = swp_entry_to_pmd(entry);
if (pmd_swp_soft_dirty(*pmd))
newpmd = pmd_swp_mksoft_dirty(newpmd);
- if (pmd_swp_uffd_wp(*pmd))
- newpmd = pmd_swp_mkuffd_wp(newpmd);
} else {
newpmd = *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 = swp_entry_to_pte(entry);
if (pte_swp_soft_dirty(oldpte))
newpte = pte_swp_mksoft_dirty(newpte);
- if (pte_swp_uffd_wp(oldpte))
- newpte = pte_swp_mkuffd_wp(newpte);
} else if (is_writable_device_private_entry(entry)) {
/*
* We do not preserve soft-dirtiness. See
--
2.39.2
next prev parent reply other threads:[~2023-04-05 14:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 14:25 [PATCH v1 0/2] mm/userfaultfd: fix and cleanup for migration entries with uffd-wp David Hildenbrand
2023-04-05 14:25 ` [PATCH v1 1/2] mm/userfaultfd: fix uffd-wp handling for THP migration entries David Hildenbrand
2023-04-05 15:12 ` Peter Xu
2023-04-05 15:17 ` David Hildenbrand
2023-04-05 15:43 ` Peter Xu
2023-04-05 15:51 ` David Hildenbrand
2023-04-05 14:25 ` David Hildenbrand [this message]
2023-04-05 15:15 ` [PATCH v1 2/2] mm/userfaultfd: don't consider uffd-wp bit of writable " Peter Xu
2023-04-05 15:17 ` [PATCH v1 0/2] mm/userfaultfd: fix and cleanup for migration entries with uffd-wp Peter Xu
2023-04-05 15:19 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230405142535.493854-3-david@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=usama.anjum@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox