From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@redhat.com>,
Gavin Guo <gavinguo@igalia.com>,
Muchun Song <muchun.song@linux.dev>, Peter Xu <peterx@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.12.y 4/5] mm,hugetlb: sort out folio locking in the faulting path
Date: Wed, 4 Nov 2026 10:58:30 -0500 [thread overview]
Message-ID: <20261104155731.3920547-4-sashal@kernel.org> (raw)
In-Reply-To: <20261104155731.3920547-1-sashal@kernel.org>
From: Oscar Salvador <osalvador@suse.de>
[ Upstream commit 9293fb4765527c0d2375eb441d045a5a75f5210d ]
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.
Link: https://lkml.kernel.org/r/20250627102904.107202-3-osalvador@suse.de
Link: https://lkml.kernel.org/r/20250630144212.156938-3-osalvador@suse.de
Signed-off-by: Oscar Salvador <osalvador@suse.de>
Suggested-by: David Hildenbrand <david@redhat.com>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Gavin Guo <gavinguo@igalia.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Stable-dep-of: 824cc56bf43c ("mm/hugetlb: fix use-after-free of a new anon folio")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/hugetlb.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4d80b8497142a..5196c1a816e38 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6116,6 +6116,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
@@ -6282,6 +6283,14 @@ 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 keep file folios locked. 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);
}
@@ -6296,7 +6305,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);
@@ -6480,15 +6490,20 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
if (flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) {
if (!huge_pte_write(vmf.orig_pte)) {
- /* hugetlb_wp() requires page locks of pte_page(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));
- if (!folio_trylock(folio)) {
+ if (folio_test_anon(folio) && !folio_trylock(folio)) {
need_wait_lock = true;
goto out_ptl;
}
folio_get(folio);
ret = hugetlb_wp(&vmf);
- folio_unlock(folio);
+ if (folio_test_anon(folio))
+ folio_unlock(folio);
folio_put(folio);
goto out_ptl;
} else if (likely(flags & FAULT_FLAG_WRITE)) {
--
2.53.0
next prev parent reply other threads:[~2026-11-04 15:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 13:39 FAILED: patch "[PATCH] mm/hugetlb: fix use-after-free of a new anon folio" failed to apply to 6.12-stable tree gregkh
2026-11-04 15:58 ` [PATCH 6.12.y 1/5] mm/hugetlb: stop using avoid_reserve flag in fork() Sasha Levin
2026-11-04 15:58 ` [PATCH 6.12.y 2/5] mm/hugetlb: rename avoid_reserve to cow_from_owner Sasha Levin
2026-11-04 15:58 ` [PATCH 6.12.y 3/5] mm,hugetlb: change mechanism to detect a COW on private mapping Sasha Levin
2026-11-04 15:58 ` Sasha Levin [this message]
2026-11-04 15:58 ` [PATCH 6.12.y 5/5] mm/hugetlb: fix use-after-free of a new anon folio Sasha Levin
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=20261104155731.3920547-4-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gavinguo@igalia.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=stable@vger.kernel.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