From: Eliav Farber <farbere@amazon.com>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>
Cc: 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>,
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>,
Matthew Wilcox <willy@infradead.org>,
Peter Xu <peterx@redhat.com>,
"Jose A. Perez de Azpillaga" <azpijr@gmail.com>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
Eliav Farber <farbere@amazon.com>
Subject: [PATCH v2 2/4] mm: don't report OOM when a huge PMD race blocks a pfn insert
Date: Thu, 12 Nov 2026 05:14:38 +0000 [thread overview]
Message-ID: <20261112051440.16140-3-farbere@amazon.com> (raw)
In-Reply-To: <20261112051440.16140-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.
get_locked_pte() cannot tell the two apart, because pte_alloc_map_lock()
folds the allocation and the map into one call. Walk to the PMD,
allocate, and map as three steps, so that only a failed allocation
returns VM_FAULT_OOM. A NULL from the map returns VM_FAULT_NOPAGE and
the access refaults, which is what a PMD leaf, a PMD that is not present
and a bad PMD that __pte_offset_map() cleared all want.
Fixes: f9e54c3a2f5b ("vfio/pci: implement huge_fault support")
Signed-off-by: Eliav Farber <farbere@amazon.com>
Suggested-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
---
v2: Split pte_alloc_map_lock() into pte_alloc() followed by
pte_offset_map_lock(), so that only a failed allocation returns
VM_FAULT_OOM and a NULL from the map returns VM_FAULT_NOPAGE. v1
called pte_alloc_map_lock() and then re-read the PMD with
pmd_trans_huge() to tell the two apart, which left the non-present
and bad-PMD cases reported as OOM. Suggested by Jose A. Perez de
Azpillaga.
mm/memory.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 0f54ee0a6d88..05ae87518206 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2866,10 +2866,24 @@ 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;
+
+ if (pte_alloc(mm, pmd))
return VM_FAULT_OOM;
+
+ /*
+ * 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.
+ */
+ pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
+ if (!pte)
+ return VM_FAULT_NOPAGE;
+
entry = ptep_get(pte);
if (!pte_none(entry)) {
if (mkwrite) {
--
2.47.3
next prev parent reply other threads:[~2026-11-12 5:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 5:14 [PATCH v2 0/4] mm: fixes for huge PFN mappings Eliav Farber
2026-11-12 5:14 ` [PATCH v2 1/4] mm: drop the huge PMD assertion from walk_to_pmd() Eliav Farber
2026-11-12 5:14 ` Eliav Farber [this message]
2026-11-12 10:07 ` [PATCH v2 2/4] mm: don't report OOM when a huge PMD race blocks a pfn insert Jose A. Perez de Azpillaga
2026-11-12 5:14 ` [PATCH v2 3/4] mm/huge_memory: don't warn when a page table blocks a huge " Eliav Farber
2026-11-13 2:29 ` Andrew Morton
2026-11-13 5:15 ` sashiko-bot
2026-11-12 5:14 ` [PATCH v2 4/4] mm/huge_memory: use the large-page PAT encoding for huge pfn mappings Eliav Farber
2026-11-12 10:08 ` Jose A. Perez de Azpillaga
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=20261112051440.16140-3-farbere@amazon.com \
--to=farbere@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=azpijr@gmail.com \
--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=willy@infradead.org \
--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.