All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Peter Xu <peterx@redhat.com>, Peter Feiner <pfeiner@google.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: [PATCH v1 2/2] mm/hugetlb: support write-faults in shared mappings
Date: Fri,  5 Aug 2022 13:03:29 +0200	[thread overview]
Message-ID: <20220805110329.80540-3-david@redhat.com> (raw)
In-Reply-To: <20220805110329.80540-1-david@redhat.com>

Let's add a safety net if we ever get (again) a write-fault on a R/O-mapped
page in a shared mapping, in which case we simply have to map the
page writable.

VM_MAYSHARE handling in hugetlb_fault() for FAULT_FLAG_WRITE
indicates that this was at least envisioned, but could never have worked
as expected. This theoretically paves the way for softdirty tracking
support in hugetlb.

Tested without the fix for softdirty tracking.

Note that there is no need to do any kind of reservation in hugetlb_fault()
in this case ... because we already have a hugetlb page mapped R/O
that we will simply map writable and we are not dealing with COW/unsharing.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 mm/hugetlb.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a18c071c294e..bbab7aa9d8f8 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5233,6 +5233,16 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma,
 	VM_BUG_ON(unshare && (flags & FOLL_WRITE));
 	VM_BUG_ON(!unshare && !(flags & FOLL_WRITE));
 
+	/* Let's take out shared mappings first, this should be a rare event. */
+	if (unlikely(vma->vm_flags & VM_MAYSHARE)) {
+		if (unshare)
+			return 0;
+		if (WARN_ON_ONCE(!(vma->vm_flags & VM_WRITE)))
+			return VM_FAULT_SIGSEGV;
+		set_huge_ptep_writable(vma, haddr, ptep);
+		return 0;
+	}
+
 	pte = huge_ptep_get(ptep);
 	old_page = pte_page(pte);
 
@@ -5767,12 +5777,11 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 	 * If we are going to COW/unshare the mapping later, we examine the
 	 * pending reservations for this page now. This will ensure that any
 	 * allocations necessary to record that reservation occur outside the
-	 * spinlock. For private mappings, we also lookup the pagecache
-	 * page now as it is used to determine if a reservation has been
-	 * consumed.
+	 * spinlock. Also lookup the pagecache page now as it is used to
+	 * determine if a reservation has been consumed.
 	 */
 	if ((flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) &&
-	    !huge_pte_write(entry)) {
+	    !(vma->vm_flags & VM_MAYSHARE) && !huge_pte_write(entry)) {
 		if (vma_needs_reservation(h, vma, haddr) < 0) {
 			ret = VM_FAULT_OOM;
 			goto out_mutex;
@@ -5780,9 +5789,7 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 		/* Just decrements count, does not deallocate */
 		vma_end_reservation(h, vma, haddr);
 
-		if (!(vma->vm_flags & VM_MAYSHARE))
-			pagecache_page = hugetlbfs_pagecache_page(h,
-								vma, haddr);
+		pagecache_page = hugetlbfs_pagecache_page(h, vma, haddr);
 	}
 
 	ptl = huge_pte_lock(h, mm, ptep);
-- 
2.35.3


  parent reply	other threads:[~2022-08-05 11:03 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05 11:03 [PATCH v1 0/2] mm/hugetlb: fix write-fault handling for shared mappings David Hildenbrand
2022-08-05 11:03 ` [PATCH v1 1/2] mm/hugetlb: fix hugetlb not supporting write-notify David Hildenbrand
2022-08-05 18:14   ` Peter Xu
2022-08-05 18:22     ` David Hildenbrand
2022-08-05 18:23     ` Mike Kravetz
2022-08-05 18:25       ` David Hildenbrand
2022-08-05 18:33         ` Mike Kravetz
2022-08-05 18:57           ` David Hildenbrand
2022-08-05 20:48             ` Mike Kravetz
2022-08-05 23:13               ` Peter Xu
2022-08-05 23:33                 ` Mike Kravetz
2022-08-08 16:10                   ` Peter Xu
2022-08-08 16:36                 ` David Hildenbrand
2022-08-08 19:28                   ` Peter Xu
2022-08-10  9:29                     ` David Hildenbrand
2022-08-05 11:03 ` David Hildenbrand [this message]
2022-08-05 18:12   ` [PATCH v1 2/2] mm/hugetlb: support write-faults in shared mappings Peter Xu
2022-08-05 18:20     ` David Hildenbrand
2022-08-08 16:05       ` Peter Xu
2022-08-08 16:25         ` David Hildenbrand
2022-08-08 20:21           ` Peter Xu
2022-08-08 22:08             ` Peter Xu
2022-08-10  9:37               ` David Hildenbrand
2022-08-10  9:45                 ` David Hildenbrand
2022-08-10 19:29                 ` Peter Xu
2022-08-10 19:40                   ` David Hildenbrand
2022-08-10 19:52                     ` Peter Xu
2022-08-10 23:55                       ` Mike Kravetz
2022-08-11  8:48                         ` David Hildenbrand
2022-08-05 23:08     ` Mike Kravetz

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=20220805110329.80540-3-david@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.com \
    --cc=pfeiner@google.com \
    --cc=songmuchun@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.