linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: rppt@linux.vnet.ibm.com,peterx@redhat.com,axelrasmussen@google.com,aarcange@redhat.com,namit@vmware.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org
Subject: [patch 04/13] userfaultfd: mark uffd_wp regardless of VM_WRITE flag
Date: Thu, 21 Apr 2022 16:35:43 -0700	[thread overview]
Message-ID: <20220421233543.ADE25C385A5@smtp.kernel.org> (raw)
In-Reply-To: <20220421163508.66028a9ac2d9fb6ea05b1342@linux-foundation.org>

From: Nadav Amit <namit@vmware.com>
Subject: userfaultfd: mark uffd_wp regardless of VM_WRITE flag

When a PTE is set by UFFD operations such as UFFDIO_COPY, the PTE is
currently only marked as write-protected if the VMA has VM_WRITE flag set.
This seems incorrect or at least would be unexpected by the users.

Consider the following sequence of operations that are being performed on
a certain page:

	mprotect(PROT_READ)
	UFFDIO_COPY(UFFDIO_COPY_MODE_WP)
	mprotect(PROT_READ|PROT_WRITE)

At this point the user would expect to still get UFFD notification when
the page is accessed for write, but the user would not get one, since the
PTE was not marked as UFFD_WP during UFFDIO_COPY.

Fix it by always marking PTEs as UFFD_WP regardless on the
write-permission in the VMA flags.

Link: https://lkml.kernel.org/r/20220217211602.2769-1-namit@vmware.com
Fixes: 292924b26024 ("userfaultfd: wp: apply _PAGE_UFFD_WP bit")
Signed-off-by: Nadav Amit <namit@vmware.com>
Acked-by: Peter Xu <peterx@redhat.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/userfaultfd.c |   15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

--- a/mm/userfaultfd.c~userfaultfd-mark-uffd_wp-regardless-of-vm_write-flag
+++ a/mm/userfaultfd.c
@@ -72,12 +72,15 @@ int mfill_atomic_install_pte(struct mm_s
 	_dst_pte = pte_mkdirty(_dst_pte);
 	if (page_in_cache && !vm_shared)
 		writable = false;
-	if (writable) {
-		if (wp_copy)
-			_dst_pte = pte_mkuffd_wp(_dst_pte);
-		else
-			_dst_pte = pte_mkwrite(_dst_pte);
-	}
+
+	/*
+	 * Always mark a PTE as write-protected when needed, regardless of
+	 * VM_WRITE, which the user might change.
+	 */
+	if (wp_copy)
+		_dst_pte = pte_mkuffd_wp(_dst_pte);
+	else if (writable)
+		_dst_pte = pte_mkwrite(_dst_pte);
 
 	dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, &ptl);
 
_


  parent reply	other threads:[~2022-04-21 23:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 23:35 incoming Andrew Morton
2022-04-21 23:35 ` [patch 01/13] mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb() Andrew Morton
2022-04-21 23:35 ` [patch 02/13] mm/memory-failure.c: skip huge_zero_page in memory_failure() Andrew Morton
2022-04-21 23:35 ` [patch 03/13] memcg: sync flush only if periodic flush is delayed Andrew Morton
2022-04-21 23:35 ` Andrew Morton [this message]
2022-04-21 23:35 ` [patch 05/13] mm, hugetlb: allow for "high" userspace addresses Andrew Morton
2022-04-21 23:35 ` [patch 06/13] selftest/vm: verify mmap addr in mremap_test Andrew Morton
2022-04-21 23:35 ` [patch 07/13] selftest/vm: verify remap destination address " Andrew Morton
2022-04-21 23:35 ` [patch 08/13] selftest/vm: support xfail " Andrew Morton
2022-04-21 23:35 ` [patch 09/13] selftest/vm: add skip support to mremap_test Andrew Morton
2022-04-21 23:36 ` [patch 10/13] oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup Andrew Morton
2022-04-21 23:36 ` [patch 11/13] MAINTAINERS: add Vincenzo Frascino to KASAN reviewers Andrew Morton
2022-04-21 23:36 ` [patch 12/13] kcov: don't generate a warning on vm_insert_page()'s failure Andrew Morton
2022-04-21 23:36 ` [patch 13/13] mm/mmu_notifier.c: fix race in mmu_interval_notifier_remove() Andrew Morton

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=20220421233543.ADE25C385A5@smtp.kernel.org \
    --to=akpm@linux-foundation.org \
    --cc=aarcange@redhat.com \
    --cc=axelrasmussen@google.com \
    --cc=linux-mm@kvack.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=namit@vmware.com \
    --cc=patches@lists.linux.dev \
    --cc=peterx@redhat.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /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