| Message ID | 20230411142512.438404-7-david@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 1462c52e9f2b99e72022ed8979bfc969894bb3da |
| Headers | show |
| Series | mm: (pte|pmd)_mkdirty() should not unconditionally allow for write access | expand |
diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 6f3af65435c8..8332e16ac97b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2235,11 +2235,10 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, entry = pte_swp_mkuffd_wp(entry); } else { entry = mk_pte(page + i, READ_ONCE(vma->vm_page_prot)); - entry = maybe_mkwrite(entry, vma); + if (write) + entry = maybe_mkwrite(entry, vma); if (anon_exclusive) SetPageAnonExclusive(page + i); - if (!write) - entry = pte_wrprotect(entry); if (!young) entry = pte_mkold(entry); /* NOTE: this may set soft-dirty too on some archs */
No need to call maybe_mkwrite() to then wrprotect if the source PMD was not writable. It's worth nothing that this now allows for PTEs to be writable even if the source PMD was not writable: if vma->vm_page_prot includes write permissions. As documented in commit 931298e103c2 ("mm/userfaultfd: rely on vma->vm_page_prot in uffd_wp_range()"), any mechanism that intends to have pages wrprotected (COW, writenotify, mprotect, uffd-wp, softdirty, ...) has to properly adjust vma->vm_page_prot upfront, to not include write permissions. If vma->vm_page_prot includes write permissions, the PTE/PMD can be writable as default. This now mimics the handling in mm/migrate.c:remove_migration_pte() and in mm/huge_memory.c:remove_migration_pmd(), which has been in place for a long time (except that 96a9c287e25d ("mm/migrate: fix wrongly apply write bit after mkdirty on sparc64") temporarily changed it). Signed-off-by: David Hildenbrand <david@redhat.com> --- mm/huge_memory.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)