From: Oscar Salvador <osalvador@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>,
Muchun Song <muchun.song@linux.dev>, Peter Xu <peterx@redhat.com>,
Gavin Guo <gavinguo@igalia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Oscar Salvador <osalvador@suse.de>
Subject: [PATCH v2 2/5] mm,hugetlb: Sort out folio locking in the faulting path
Date: Fri, 20 Jun 2025 14:30:11 +0200 [thread overview]
Message-ID: <20250620123014.29748-3-osalvador@suse.de> (raw)
In-Reply-To: <20250620123014.29748-1-osalvador@suse.de>
Recent conversations showed that there was a misunderstanding about why we
were locking the folio prior to call in hugetlb_wp().
In fact, as soon as we have the folio mapped into the pagetables, we no longer
need to hold it locked, because we know that no concurrent truncation could have
happened.
There is only one case where the folio needs to be locked, and that is when we
are handling an anonymous folio, because hugetlb_wp() will check whether it can
re-use it exclusively for the process that is faulting it in.
So, pass the folio locked to hugetlb_wp() when that is the case.
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
mm/hugetlb.c | 43 +++++++++++++++++++++++++++++++++----------
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 175edafeec67..1a5f713c1e4c 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6437,6 +6437,7 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping,
pte_t new_pte;
bool new_folio, new_pagecache_folio = false;
u32 hash = hugetlb_fault_mutex_hash(mapping, vmf->pgoff);
+ bool folio_locked = true;
/*
* Currently, we are forced to kill the process in the event the
@@ -6602,6 +6603,11 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping,
hugetlb_count_add(pages_per_huge_page(h), mm);
if ((vmf->flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) {
+ /* No need to lock file folios. See comment in hugetlb_fault() */
+ if (!anon_rmap) {
+ folio_locked = false;
+ folio_unlock(folio);
+ }
/* Optimization, do the COW without a second fault */
ret = hugetlb_wp(vmf);
}
@@ -6616,7 +6622,8 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping,
if (new_folio)
folio_set_hugetlb_migratable(folio);
- folio_unlock(folio);
+ if (folio_locked)
+ folio_unlock(folio);
out:
hugetlb_vma_unlock_read(vma);
@@ -6636,7 +6643,8 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping,
if (new_folio && !new_pagecache_folio)
restore_reserve_on_error(h, vma, vmf->address, folio);
- folio_unlock(folio);
+ if (folio_locked)
+ folio_unlock(folio);
folio_put(folio);
goto out;
}
@@ -6670,7 +6678,7 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
{
vm_fault_t ret;
u32 hash;
- struct folio *folio;
+ struct folio *folio = NULL;
struct hstate *h = hstate_vma(vma);
struct address_space *mapping;
struct vm_fault vmf = {
@@ -6687,6 +6695,7 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
* be hard to debug if called functions make assumptions
*/
};
+ bool folio_locked = false;
/*
* Serialize hugepage allocation and instantiation, so that we don't
@@ -6801,13 +6810,24 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
/* Fallthrough to CoW */
}
- /* hugetlb_wp() requires page locks of pte_page(vmf.orig_pte) */
- folio = page_folio(pte_page(vmf.orig_pte));
- folio_lock(folio);
- folio_get(folio);
-
if (flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) {
if (!huge_pte_write(vmf.orig_pte)) {
+ /*
+ * Anonymous folios need to be lock since hugetlb_wp()
+ * checks whether we can re-use the folio exclusively
+ * for us in case we are the only user of it.
+ */
+ folio = page_folio(pte_page(vmf.orig_pte));
+ folio_get(folio);
+ if (folio_test_anon(folio)) {
+ spin_unlock(vmf.ptl);
+ folio_lock(folio);
+ folio_locked = true;
+ spin_lock(vmf.ptl);
+ if (unlikely(!pte_same(vmf.orig_pte, huge_ptep_get(mm,
+ vmf.address, vmf.pte))))
+ goto out_put_page;
+ }
ret = hugetlb_wp(&vmf);
goto out_put_page;
} else if (likely(flags & FAULT_FLAG_WRITE)) {
@@ -6819,8 +6839,11 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
flags & FAULT_FLAG_WRITE))
update_mmu_cache(vma, vmf.address, vmf.pte);
out_put_page:
- folio_unlock(folio);
- folio_put(folio);
+ if (folio) {
+ if (folio_locked)
+ folio_unlock(folio);
+ folio_put(folio);
+ }
out_ptl:
spin_unlock(vmf.ptl);
out_mutex:
--
2.50.0
next prev parent reply other threads:[~2025-06-20 12:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-20 12:30 [PATCH v2 0/5] Misc rework on hugetlb " Oscar Salvador
2025-06-20 12:30 ` [PATCH v2 1/5] mm,hugetlb: Change mechanism to detect a COW on private mapping Oscar Salvador
2025-06-23 14:09 ` David Hildenbrand
2025-06-25 7:49 ` Oscar Salvador
2025-06-25 10:13 ` David Hildenbrand
2025-06-20 12:30 ` Oscar Salvador [this message]
2025-06-23 14:11 ` [PATCH v2 2/5] mm,hugetlb: Sort out folio locking in the faulting path David Hildenbrand
2025-06-25 7:47 ` Oscar Salvador
2025-06-25 20:47 ` Oscar Salvador
2025-06-20 12:30 ` [PATCH v2 3/5] mm,hugetlb: Rename anon_rmap to new_anon_folio and make it boolean Oscar Salvador
2025-06-20 14:28 ` Oscar Salvador
2025-06-23 14:13 ` David Hildenbrand
2025-06-25 7:43 ` Oscar Salvador
2025-06-20 12:30 ` [PATCH v2 4/5] mm,hugetlb: Drop obsolete comment about non-present pte and second faults Oscar Salvador
2025-06-20 12:30 ` [PATCH v2 5/5] mm,hugetlb: Drop unlikelys from hugetlb_fault Oscar Salvador
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=20250620123014.29748-3-osalvador@suse.de \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gavinguo@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=peterx@redhat.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