From: Eliav Farber <farbere@amazon.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
"Ryan Roberts" <ryan.roberts@arm.com>,
Dev Jain <dev.jain@arm.com>, Barry Song <baohua@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, <x86@kernel.org>,
William Kucharski <william.kucharski@linux.dev>,
Vishal Moola <vishal.moola@gmail.com>,
"Alex Williamson" <alex@shazbot.org>,
Peter Xu <peterx@redhat.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Eliav Farber <farbere@amazon.com>
Subject: [PATCH 2/4] mm: don't report OOM when a huge PMD race blocks a pfn insert
Date: Wed, 11 Nov 2026 14:06:53 +0000 [thread overview]
Message-ID: <20261111140655.34281-3-farbere@amazon.com> (raw)
In-Reply-To: <20261111140655.34281-1-farbere@amazon.com>
insert_pfn() maps the PTE with get_locked_pte() and treats a NULL return
as an allocation failure. pte_offset_map_lock() also returns NULL when
the PMD is a leaf, which a VM_PFNMAP mapping with both ->fault and
->huge_fault can hit: an order-0 fault that passed handle_pte_fault()'s
pmd_none() check can reach insert_pfn() after a concurrent huge fault
installed a PMD leaf over the same address. The task then takes a
VM_FAULT_OOM for a mapping that is perfectly healthy. Changing an mm's
THP policy while another thread faults the same PMD, for example with
prctl(PR_SET_THP_DISABLE), is enough to produce the mixed orders.
Walk to the PMD first and tell the two cases apart: a failed PTE
allocation stays VM_FAULT_OOM, while a PMD leaf returns VM_FAULT_NOPAGE
so that the access refaults onto the huge entry.
Fixes: f9e54c3a2f5b ("vfio/pci: implement huge_fault support")
Signed-off-by: Eliav Farber <farbere@amazon.com>
---
mm/memory.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 0f54ee0a6d88..b7b89d041f42 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2866,10 +2866,25 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma, unsigned long addr,
struct mm_struct *mm = vma->vm_mm;
pte_t *pte, entry;
spinlock_t *ptl;
+ pmd_t *pmd;
- pte = get_locked_pte(mm, addr, &ptl);
- if (!pte)
+ pmd = walk_to_pmd(mm, addr);
+ if (!pmd)
+ return VM_FAULT_OOM;
+
+ pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
+ if (!pte) {
+ /*
+ * A concurrent ->huge_fault may have installed a PMD leaf over
+ * addr, which pte_offset_map_lock() refuses to walk. The
+ * mapping is fine, so let the access refault instead of
+ * reporting a failed allocation.
+ */
+ if (pmd_trans_huge(pmdp_get_lockless(pmd)))
+ return VM_FAULT_NOPAGE;
return VM_FAULT_OOM;
+ }
+
entry = ptep_get(pte);
if (!pte_none(entry)) {
if (mkwrite) {
--
2.47.3
next prev parent reply other threads:[~2026-11-11 14:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 14:06 [PATCH 0/4] mm: fixes for huge PFN mappings Eliav Farber
2026-11-11 14:06 ` [PATCH 1/4] mm: drop the huge PMD assertion from walk_to_pmd() Eliav Farber
2026-11-11 16:52 ` Jose A. Perez de Azpillaga
2026-11-11 14:06 ` Eliav Farber [this message]
2026-11-11 16:54 ` [PATCH 2/4] mm: don't report OOM when a huge PMD race blocks a pfn insert Jose A. Perez de Azpillaga
2026-11-12 4:56 ` Farber, Eliav
2026-11-12 14:07 ` sashiko-bot
2026-11-11 14:06 ` [PATCH 3/4] mm/huge_memory: don't warn when a page table blocks a huge " Eliav Farber
2026-11-11 16:54 ` Jose A. Perez de Azpillaga
2026-11-12 14:07 ` sashiko-bot
2026-11-11 14:06 ` [PATCH 4/4] mm/huge_memory: use the large-page PAT encoding for huge pfn mappings Eliav Farber
2026-11-11 16:54 ` Jose A. Perez de Azpillaga
2026-11-12 4:58 ` Farber, Eliav
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=20261111140655.34281-3-farbere@amazon.com \
--to=farbere@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hpa@zytor.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=nico.pache@linux.dev \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=vishal.moola@gmail.com \
--cc=william.kucharski@linux.dev \
--cc=x86@kernel.org \
--cc=ziy@nvidia.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.