From: Eliav Farber <farbere@amazon.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.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>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Eliav Farber <farbere@amazon.com>
Subject: [PATCH 3/4] mm/char-mem: implement huge_fault support for /dev/mem
Date: Wed, 11 Nov 2026 11:30:44 +0000 [thread overview]
Message-ID: <20261111113045.35368-4-farbere@amazon.com> (raw)
In-Reply-To: <20261111113045.35368-1-farbere@amazon.com>
/dev/mem is commonly used to map large physical regions (reserved
memory, device memory) into userspace. mmap_mem_prepare() maps the whole
range at mmap() time with 4K PTEs, however large and well aligned it is,
which costs many page-table entries and TLB misses.
Map non-COW mappings on fault instead, as vfio-pci does since commit
f9e54c3a2f5b ("vfio/pci: implement huge_fault support"): request
MMAP_PFN_TRACK rather than an eager remap, so the VMA is set up and its
memory type tracked as before, and add ->fault/->huge_fault handlers
that map the faulting window with vmf_insert_pfn_order(), using a PMD or
PUD where alignment allows. COW mappings cannot be populated by
vmf_insert_pfn*() and stay eager; if revoke_iomem() zaps them, the fault
handler refuses them with SIGBUS, as before.
The handler re-checks range_is_allowed(): with CONFIG_IO_STRICT_DEVMEM,
revoke_iomem() zaps a range once a driver claims it, and a fault must
not map it back in. With CONFIG_STRICT_DEVMEM this costs one
devmem_is_allowed() call per page of the faulting window.
Unlike the eager mapping, a revoke is not permanent: once the driver
releases the range, a fault repopulates the mapping, as a fresh mmap()
of it would.
generic_access_phys() only follows present PTEs, so .access now faults
the page in first; otherwise remote access (ptrace, /proc/pid/mem) to an
untouched page would fail. A mapping that does not permit the fault,
PROT_NONE for example, keeps that gap: fixup_user_fault() refuses it,
where the eager mapping left a present PTE.
Validation at mmap() time is unchanged, except for the L1TF pfn check:
the eager mapping rejected a disallowed pfn with -EAGAIN from mmap(),
where the fault handler now raises SIGBUS on first touch.
vmf_insert_pfn() refuses the zero pfn, where remap_pfn_range() mapped
it, so a page of RAM that happens to be the zero page now SIGBUSes.
That needs /dev/mem access to RAM, i.e. a kernel without
CONFIG_STRICT_DEVMEM.
Without huge PFN mappings, or for small or unaligned mappings, the
range is populated one page per fault, paid only for pages that are
actually touched.
Signed-off-by: Eliav Farber <farbere@amazon.com>
---
mm/char-mem.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 99 insertions(+), 4 deletions(-)
diff --git a/mm/char-mem.c b/mm/char-mem.c
index c5761ddedbd7..b9ed8473baeb 100644
--- a/mm/char-mem.c
+++ b/mm/char-mem.c
@@ -318,9 +318,92 @@ static inline int private_mapping_ok(struct vm_area_desc *desc)
}
#endif
+#ifdef CONFIG_MMU
+/*
+ * Populate /dev/mem mappings on fault, using a PMD or PUD mapping where the
+ * architecture, the fault address and the pfn allow it.
+ */
+static vm_fault_t mmap_mem_huge_fault(struct vm_fault *vmf, unsigned int order)
+{
+ unsigned long addr = vmf->address & ~((PAGE_SIZE << order) - 1);
+ struct vm_area_struct *vma = vmf->vma;
+ unsigned long pfn;
+
+ /*
+ * COW mappings are mapped eagerly at mmap() time and only lose their
+ * pages to revoke_iomem(); keep them unmapped, as without a fault
+ * handler. vmf_insert_pfn*() would also BUG_ON them.
+ */
+ if (vma_is_cow_mapping(vma))
+ return VM_FAULT_SIGBUS;
+
+ /*
+ * vm_pgoff is the base pfn of the mapping. vmf_pfn_order_ok() ignores
+ * pfn if the window starts below vm_start.
+ */
+ pfn = vma->vm_pgoff + ((addr - vma->vm_start) >> PAGE_SHIFT);
+ if (!vmf_pfn_order_ok(vmf, pfn, order))
+ return VM_FAULT_FALLBACK;
+
+ /*
+ * Access was checked at mmap() time, but with CONFIG_IO_STRICT_DEVMEM
+ * revoke_iomem() zaps the mapping once a driver claims part of the
+ * range. Re-check here so a revoked page is not faulted back in. Like
+ * the mmap()-time check, it is not serialised against revoke_iomem(),
+ * so a fault that passed it can still install a page revoked right
+ * after.
+ */
+ if (!range_is_allowed(pfn, PAGE_SIZE << order))
+ return order ? VM_FAULT_FALLBACK : VM_FAULT_SIGBUS;
+
+ return vmf_insert_pfn_order(vmf, pfn, order);
+}
+
+static vm_fault_t mmap_mem_fault(struct vm_fault *vmf)
+{
+ return mmap_mem_huge_fault(vmf, 0);
+}
+#endif /* CONFIG_MMU */
+
+#ifdef CONFIG_HAVE_IOREMAP_PROT
+/*
+ * generic_access_phys() only follows present PTEs, and a lazily populated
+ * mapping has none for pages the target has not touched yet. Fault the page in
+ * first, so that remote access (ptrace, /proc/pid/mem) keeps working.
+ *
+ * fixup_user_fault() refuses a fault the vma does not permit, so an untouched
+ * page of a mapping without VM_READ stays unreadable, where the eager mapping
+ * left a present PTE.
+ */
+static int mmap_mem_access(struct vm_area_struct *vma, unsigned long addr,
+ void *buf, int len, int write)
+{
+ unsigned int fault_flags = FAULT_FLAG_REMOTE;
+
+ if (write)
+ fault_flags |= FAULT_FLAG_WRITE;
+
+ /*
+ * COW mappings are populated at mmap() time, and a write fault would
+ * copy the page instead. With unlocked == NULL, fixup_user_fault()
+ * keeps the mmap lock held and the vma valid.
+ */
+ if (!vma_is_cow_mapping(vma))
+ fixup_user_fault(vma->vm_mm, addr, fault_flags, NULL);
+
+ return generic_access_phys(vma, addr, buf, len, write);
+}
+#endif
+
static const struct vm_operations_struct mmap_mem_ops = {
+#ifdef CONFIG_MMU
+ .fault = mmap_mem_fault,
+#endif
+#ifdef CONFIG_ARCH_SUPPORTS_HUGE_PFNMAP
+ .huge_fault = mmap_mem_huge_fault,
+#endif
#ifdef CONFIG_HAVE_IOREMAP_PROT
- .access = generic_access_phys
+ .access = mmap_mem_access,
#endif
};
@@ -356,11 +439,23 @@ static int mmap_mem_prepare(struct vm_area_desc *desc)
desc->page_prot);
desc->vm_ops = &mmap_mem_ops;
-
- /* Remap-pfn-range will mark the range with the I/O flag. */
- mmap_action_remap_full(desc, desc->pgoff);
desc->action.error_override = -EAGAIN;
+ if (vma_desc_is_cow_mapping(desc)) {
+ /*
+ * vmf_insert_pfn*() cannot populate COW mappings: map them now.
+ * Remap-pfn-range will mark the range with the I/O flag.
+ */
+ mmap_action_remap_full(desc, desc->pgoff);
+ return 0;
+ }
+
+ /*
+ * Populate on fault (see mmap_mem_huge_fault()). Tracking the PFN range
+ * keeps its memory type reserved, for PAT conflict detection.
+ */
+ mmap_action_pfn_track(desc, desc->pgoff);
+
return 0;
}
--
2.47.3
next prev parent reply other threads:[~2026-11-11 11:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 11:30 [PATCH 0/4] mm, uio: huge PFN mappings for /dev/mem and UIO Eliav Farber
2026-11-11 11:30 ` [PATCH 1/4] mm: add MMAP_PFN_TRACK action and pfn_range_track() for lazy PFN maps Eliav Farber
2026-11-11 11:30 ` [PATCH 2/4] mm: add vmf_insert_pfn_order() and vmf_pfn_order_ok() helpers Eliav Farber
2026-11-11 11:30 ` Eliav Farber [this message]
2026-11-11 11:30 ` [PATCH 4/4] uio: implement huge_fault support for physical mappings Eliav Farber
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=20261111113045.35368-4-farbere@amazon.com \
--to=farbere@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@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
all inboxes | Powered by JetHome®