s390/mm: Batch PTE updates in lazy MMU mode
Subsystems (9)
Alexander Gordeev
maintainerv4 cover s390/mm: Batch PTE updates in lazy MMU mode
Hi All!
This is v4 of the batched PTE updates in lazy MMU mode rework.
The presented implementation sets up per-cpu caches in the s390-specific hotplug callbacks as opposed to CPUHP_BP_PREPARE_DYN hooks. I like this approach better, since it locates the SMP-related lowcore initialization in one place. But that is up for discussion.
Changes since v3:
- all prerequisite patches are landed in -next and removed from the series
Changes since v2:
- lazy_mmu_mode_enable_for_pte_range() renamed to lazy_mmu_mode_enable_with_ptes() (David Hildenbrand)
- patch "mm/pgtable: Fix bogus comment to clear_not_present_full_ptes()" is dropped (David Hildenbrand)
- direct PTE dereferencing KASAN sanitizer added (Heiko Carstens)
- CONFIG_IPTE_BATCH option is dropped (Heiko Carstens)
- PTE_POISON changed from zero to 0x800 (Heiko Carstens)
- allocate per-cpu caches on CPU hot-plug (Heiko Carstens)
- introduced a lowcore field for fast lazy mode checking (Heiko Carstens)
- few minor code changes (Heiko Carstens)
Changes since v1:
- lazy_mmu_mode_enable_pte() renamed to lazy_mmu_mode_enable_for_pte_range()
- lazy_mmu_mode_enable_for_pte_range() semantics clarified
- some sashiko comments addressed [1] including one bug fix [1]
- patches 2-4 added
1. https://sashiko.dev/#/patchset/cover.1774420056.git.agordeev%40linux.ibm.com
This series addresses an s390-specific aspect of how page table entries are modified. In many cases, changing a valid PTE (for example, setting or clearing a hardware bit) requires issuing an Invalidate Page Table Entry (IPTE) instruction beforehand.
A disadvantage of the IPTE instruction is that it may initiate a machine-wide quiesce state. This state acts as an expensive global hardware lock and should be avoided whenever possible.
Currently, IPTE is invoked for each individual PTE update in most code paths. However, the instruction itself supports invalidating multiple PTEs at once, covering up to 256 entries. Using this capability can significantly reduce the number of quiesce events, with a positive impact on overall system performance. At present, this feature is not utilized.
An effort was therefore made to identify kernel code paths that update large numbers of consecutive PTEs. Such updates can be batched and handled by a single IPTE invocation, leveraging the hardware support described above.
A natural candidate for this optimization is page-table walkers that change attributes of memory ranges and thus modify contiguous ranges of PTEs. Many memory-management system calls enter lazy MMU mode while updating such ranges.
This lazy MMU mode can be leveraged to build on the already existing infrastructure and implement a software-level lazy MMU mechanism, allowing expensive PTE invalidations on s390 to be batched.
Alexander Gordeev (4):
mm: Make lazy MMU mode context-aware
s390/mm: Batch PTE updates in lazy MMU mode mm/kasan: Introduce helpers for lazy MMU mode sanitizer s390/mm: Lazy MMU mode sanitizer
arch/s390/Kconfig | 1 + arch/s390/include/asm/lazy_mmu.h | 9 + arch/s390/include/asm/lowcore.h | 2 +- arch/s390/include/asm/pgtable.h | 163 +++++++++++-- arch/s390/kernel/setup.c | 2 + arch/s390/kernel/smp.c | 7 + arch/s390/mm/Makefile | 2 +- arch/s390/mm/lazy_mmu.c | 401 +++++++++++++++++++++++++++++++ arch/s390/mm/pgtable.c | 8 +- fs/proc/task_mmu.c | 2 +- include/linux/kasan.h | 16 ++ include/linux/pgtable.h | 46 ++++ mm/kasan/common.c | 10 + mm/kasan/kasan.h | 2 + mm/madvise.c | 8 +- mm/memory.c | 8 +- mm/mprotect.c | 2 +- mm/mremap.c | 2 +- mm/vmalloc.c | 6 +- 19 files changed, 659 insertions(+), 38 deletions(-) create mode 100644 arch/s390/include/asm/lazy_mmu.h create mode 100644 arch/s390/mm/lazy_mmu.c
Signature · 1 line
2.53.0
Alexander Gordeev
maintainerPATCH v4 1/4 mm: Make lazy MMU mode context-aware
Lazy MMU mode is assumed to be context-independent, in the sense that it does not need any additional information while operating. However, the s390 architecture benefits from knowing the exact page table entries being modified.
Introduce lazy_mmu_mode_enable_with_ptes(), which is provided with the process address space and the page table being operated on. This information is required to enable s390-specific optimizations.
The function takes parameters that are typically passed to page- table level walkers, which implies that the span of PTE entries never crosses a page table boundary.
Architectures that do not require such information simply do not need to define the lazy_mmu_mode_enable_with_ptes() callback.
--- fs/proc/task_mmu.c | 2 +- include/linux/pgtable.h | 46 +++++++++++++++++++++++++++++++++++++++++ mm/madvise.c | 8 +++---- mm/memory.c | 8 +++---- mm/mprotect.c | 2 +- mm/mremap.c | 2 +- mm/vmalloc.c | 6 +++--- 7 files changed, 60 insertions(+), 14 deletions(-)
fs/proc/task_mmu.c +1 -1
@@ -2842,7 +2842,7 @@ static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long start,return 0 ; } -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (vma->vm_mm, start, end, start_pte);if ((p->arg.flags &PM_SCAN_WP_MATCHING ) && !p->vec_out) {/* Fast path for performing exclusive WP */
include/linux/pgtable.h +46 -0
58 lines not on this page · raw message
mm/madvise.c +4 -4
@@ -453,7 +453,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,if (!start_pte)return 0 ;flush_tlb_batched_pending (mm); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, addr, end, start_pte);for (; addr < end; pte += nr, addr += nr *PAGE_SIZE ) { nr =1 ; ptent =ptep_get (pte);
@@ -508,7 +508,7 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,if (!start_pte)break ;flush_tlb_batched_pending (mm); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, addr, end, start_pte);if (!err) nr =0 ;continue ;
@@ -675,7 +675,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,if (!start_pte)return 0 ;flush_tlb_batched_pending (mm); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, addr, end, start_pte);for (; addr != end; pte += nr, addr +=PAGE_SIZE * nr) { nr =1 ; ptent =ptep_get (pte);
@@ -735,7 +735,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,if (!start_pte)break ;flush_tlb_batched_pending (mm); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, addr, end, pte);if (!err) nr =0 ;continue ;
mm/memory.c +4 -4
@@ -1272,7 +1272,7 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,spin_lock_nested (src_ptl,SINGLE_DEPTH_NESTING ); orig_src_pte = src_pte; orig_dst_pte = dst_pte; -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (src_mm, addr, end, src_pte); do { nr = 1;
@@ -1922,7 +1922,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,return addr;flush_tlb_batched_pending (mm); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, addr, end, start_pte); do { bool any_skipped = false;
@@ -2919,7 +2919,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd, mapped_pte = pte =pte_alloc_map_lock (mm, pmd, addr, &ptl);if (!pte)return -ENOMEM ; -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, addr, end, mapped_pte); do { BUG_ON(!pte_none(ptep_get(pte))); if (!pfn_modify_allowed(pfn, prot)) {
@@ -3330,7 +3330,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,return -EINVAL ; } -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, addr, end, mapped_pte);if (fn) { do {
mm/mprotect.c +1 -1
@@ -337,7 +337,7 @@ static long change_pte_range(struct mmu_gather *tlb, is_private_single_threaded =vma_is_single_threaded_private (vma);flush_tlb_batched_pending (vma->vm_mm); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (vma->vm_mm, addr, end, pte); do { nr_ptes = 1; oldpte = ptep_get(pte);
mm/mremap.c +1 -1
@@ -260,7 +260,7 @@ static int move_ptes(struct pagetable_move_control *pmc,if (new_ptl != old_ptl)spin_lock_nested (new_ptl,SINGLE_DEPTH_NESTING );flush_tlb_batched_pending (vma->vm_mm); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (mm, old_addr, old_end, old_ptep);for (; old_addr < old_end; old_ptep += nr_ptes, old_addr += nr_ptes *PAGE_SIZE , new_ptep += nr_ptes, new_addr += nr_ptes *PAGE_SIZE ) {
mm/vmalloc.c +3 -3
@@ -108,7 +108,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,if (!pte)return -ENOMEM ; -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (&init_mm, addr, end, pte); do { if (unlikely(!pte_none(ptep_get(pte)))) {
@@ -371,7 +371,7 @@ static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,unsigned long size =PAGE_SIZE ; pte =pte_offset_kernel (pmd, addr); -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (&init_mm, addr, end, pte); do { #ifdef CONFIG_HUGETLB_PAGE
@@ -538,7 +538,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,if (!pte)return -ENOMEM ; -lazy_mmu_mode_enable (); +lazy_mmu_mode_enable_with_ptes (&init_mm, addr, end, pte); do { struct page *page = pages[*nr];
Signature · 1 line
2.53.0
Alexander Gordeev
maintainerPATCH v4 2/4 s390/mm: Batch PTE updates in lazy MMU mode
In reply to Alexander GordeevMake use of the IPTE instruction's "Additional Entries" field to invalidate multiple PTEs in one go while in lazy MMU mode. This is the mode in which many memory-management system calls (like mremap(), mprotect(), etc.) update memory attributes.
To achieve that, the set_pte() and ptep_get() primitives use a per-CPU cache to store and retrieve PTE values and apply the cached values to the real page table once lazy MMU mode is left.
The same is done for memory-management platform callbacks that would otherwise cause intense per-PTE IPTE traffic, reducing the number of IPTE instructions from up to PTRS_PER_PTE to a single instruction in the best case. The average reduction is of course smaller.
Since all existing page table iterators called in lazy MMU mode handle one table at a time, the per-CPU cache does not need to be larger than PTRS_PER_PTE entries. That also naturally aligns with the IPTE instruction, which must not cross a page table boundary.
Before this change, the system calls did:
lazy_mmu_mode_enable_pte() ... <update PTEs> // up to PTRS_PER_PTE single-IPTEs ... lazy_mmu_mode_disable()
With this change, the system calls do:
lazy_mmu_mode_enable_pte()
...
<store new PTE values in the per-CPU cache>
...
lazy_mmu_mode_disable() // apply cache with one multi-IPTE
When applied to large memory ranges, some system calls show significant speedups:
mprotect() ~15x
munmap() ~3x
mremap() ~28xAt the same time, fork() shows a measurable slowdown of ~1.5x.
The overall results depend on memory size and access patterns, but the change generally does not degrade performance.
In addition to a process-wide impact, the rework affects the whole Central Electronics Complex (CEC). Each (global) IPTE instruction initiates a quiesce state in a CEC, so reducing the number of IPTE calls relieves CEC-wide quiesce traffic.
In an extreme case of mprotect() contiguously triggering the quiesce state on four LPARs in parallel, measurements show ~25x fewer quiesce events.
--- arch/s390/Kconfig | 1 + arch/s390/include/asm/lazy_mmu.h | 9 + arch/s390/include/asm/lowcore.h | 2 +- arch/s390/include/asm/pgtable.h | 157 +++++++++++-- arch/s390/kernel/setup.c | 2 + arch/s390/kernel/smp.c | 7 + arch/s390/mm/Makefile | 2 +- arch/s390/mm/lazy_mmu.c | 382 +++++++++++++++++++++++++++++++ arch/s390/mm/pgtable.c | 8 +- 9 files changed, 546 insertions(+), 24 deletions(-) create mode 100644 arch/s390/include/asm/lazy_mmu.h create mode 100644 arch/s390/mm/lazy_mmu.c
arch/s390/Kconfig +1 -0
@@ -97,6 +97,7 @@ config S390 select ARCH_HAS_GCOV_PROFILE_ALL select ARCH_HAS_GIGANTIC_PAGE select ARCH_HAS_KCOV + select ARCH_HAS_LAZY_MMU_MODE select ARCH_HAS_MEMBARRIER_SYNC_CORE select ARCH_HAS_MEM_ENCRYPT select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
arch/s390/include/asm/lazy_mmu.h new file +9 -0
@@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __LAZY_MMU_H +#define __LAZY_MMU_H + +void lazy_mmu_online_boot_cpu (void ); +int lazy_mmu_online_cpu (gfp_t gfp,unsigned int cpu); +void lazy_mmu_offline_cpu (unsigned int cpu); + +#endif /* __LAZY_MMU_H */
arch/s390/include/asm/lowcore.h +1 -1
@@ -163,7 +163,7 @@ struct lowcore {__s32 preempt_count;/* 0x03a8 */ __u32 spinlock_lockval;/* 0x03ac */ __u32 spinlock_index;/* 0x03b0 */ -__u8 pad_0x03b4[0x03b8 -0x03b4 ];/* 0x03b4 */ +__s32 lazy_mmu_count;/* 0x03b4 */ __u64 percpu_offset;/* 0x03b8 */ __u8 percpu_register;/* 0x03c0 */ __u8 pad_0x03c1[0x0400 -0x03c1 ];/* 0x03c1 */
arch/s390/include/asm/pgtable.h +139 -18
220 lines not on this page · raw message
arch/s390/kernel/setup.c +2 -0
@@ -77,6 +77,7 @@#include <asm/maccess.h> #include <asm/uv.h> #include <asm/asm-offsets.h> +#include <asm/lazy_mmu.h> #include "entry.h" /*
@@ -1012,5 +1013,6 @@ void __init setup_arch(char **cmdline_p)void __init arch_cpu_finalize_init (void ) { +lazy_mmu_online_boot_cpu ();sclp_init (); }
arch/s390/kernel/smp.c +7 -0
@@ -59,6 +59,7 @@#include <asm/topology.h> #include <asm/vdso.h> #include <asm/maccess.h> +#include <asm/lazy_mmu.h> #include "entry.h" enum {
@@ -866,6 +867,11 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle) rc =pcpu_alloc_lowcore (pcpu, cpu);if (rc)return rc; + rc =lazy_mmu_online_cpu (GFP_KERNEL , cpu); +if (rc) { +pcpu_free_lowcore (pcpu, cpu); +return rc; + }/* * Make sure global control register contents do not change * until new CPU has initialized control registers.
@@ -921,6 +927,7 @@ void __cpu_die(unsigned int cpu) pcpu =per_cpu_ptr (&pcpu_devices, cpu);while (!pcpu_stopped (pcpu))cpu_relax (); +lazy_mmu_offline_cpu (cpu);pcpu_free_lowcore (pcpu, cpu);cpumask_clear_cpu (cpu,mm_cpumask (&init_mm));cpumask_clear_cpu (cpu, &init_mm.context.cpu_attach_mask);
arch/s390/mm/Makefile +1 -1
@@ -3,7 +3,7 @@ # Makefile for the linux s390-specific parts of the memory manager. # -obj-y := init.o fault.o extmem.o mmap.o vmem.o maccess.o +obj-y := init.o fault.o extmem.o mmap.o vmem.o maccess.o lazy_mmu.o obj-y += page-states.o pageattr.o pgtable.o pgalloc.o extable.o obj-$(CONFIG_CMM) += cmm.o
arch/s390/mm/lazy_mmu.c new file +382 -0
382 lines not on this page · raw message
arch/s390/mm/pgtable.c +4 -4
@@ -166,14 +166,14 @@ pte_t ptep_xchg_lazy(struct mm_struct *mm, unsigned long addr, }EXPORT_SYMBOL (ptep_xchg_lazy); -pte_t ptep_modify_prot_start (struct vm_area_struct *vma,unsigned long addr, -pte_t *ptep) +pte_t ___ptep_modify_prot_start (struct vm_area_struct *vma,unsigned long addr, +pte_t *ptep) {return ptep_flush_lazy (vma->vm_mm, addr, ptep,1 ); } -void ptep_modify_prot_commit (struct vm_area_struct *vma,unsigned long addr, -pte_t *ptep,pte_t old_pte,pte_t pte) +void ___ptep_modify_prot_commit (struct vm_area_struct *vma,unsigned long addr, +pte_t *ptep,pte_t old_pte,pte_t pte) {set_pte (ptep, pte); }
Signature · 1 line
2.53.0
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Critical] Deferred PTE updates to a per-CPU cache break synchronization with lockless page table walkers…
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Deferred PTE updates to a per-CPU cache break synchronization with lockless page table walkers like GUP-fast, allowing them to pin pages being concurrently write-protected for COW.
- [High] The lazy MMU cache bypasses the full=1 TLB flush optimization during process teardown, causing an O(N) IPTE storm.
--
commit 38614c455538c6b6144011b070bbbf41513506e6
Author: Alexander Gordeev <[email protected]>
s390/mm: Batch PTE updates in lazy MMU mode
This commit introduces a per-CPU cache to batch PTE updates while in lazy MMU mode. By caching PTE changes and applying them simultaneously with the IPTE instruction's "Additional Entries" feature, it reduces overall IPTE traffic.
Quoted 3 lines
arch/s390/include/asm/pgtable.h +0
-0
[ ... ]
arch/s390/include/asm/pgtable.h static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, · line 1376
Quoted 10 lines
arch/s390/include/asm/pgtable.h +1
-5@@ -1259,11 +1373,13 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, {pte_t res; -if (full) { - res =ptep_get (ptep); -set_pte (ptep,__pte (_PAGE_INVALID)); - }else { - res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); +if (!lazy_mmu_ptep_get_and_clear (addr, ptep, &res)) {
[Severity: High]
Does checking lazy_mmu_ptep_get_and_clear() before the 'full' flag bypass the teardown optimization and cause an IPTE storm?
During process teardown, exit_mmap() and zap_pte_range() use ptep_get_and_clear_full(..., full=1) to clear PTEs without issuing individual TLB invalidations, deferring the flush to a global teardown at the end. If lazy_mmu_mode_enable_with_ptes() is active, this intercepts the call, writes _PAGE_INVALID to the cache, and bypasses the if (full) path.
Later, when lazy_mmu_mode_disable() flushes the cache, it calls __invalidate_pte_range() in arch/s390/mm/lazy_mmu.c:
static void __invalidate_pte_range(...)
{
...
if (cpu_has_tlb_lc() && ...)
__ptep_ipte_range(addr, nr_ptes - 1, ptep, IPTE_LOCAL);
else
__ptep_ipte_range(addr, nr_ptes - 1, ptep, IPTE_GLOBAL);
...
}This unconditionally executes batched IPTE instructions for all cached PTEs. For multi-threaded processes, does this turn an O(1) TLB flush operation into an O(N) global IPTE broadcast, causing a regression in system performance during process termination?
Quoted 8 lines
arch/s390/include/asm/pgtable.h +6
-0+if (full) { + res =__ptep_get (ptep); +__set_pte (ptep,__pte (_PAGE_INVALID)); + }else { + res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); + } }page_table_check_pte_clear (mm, addr, res);
[ ... ]
arch/s390/include/asm/pgtable.h static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, · line 1410
Quoted 10 lines
arch/s390/include/asm/pgtable.h +2
-3@@ -1289,10 +1405,15 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,static inline void ptep_set_wrprotect (struct mm_struct *mm,unsigned long addr,pte_t *ptep) { -pte_t pte =ptep_get (ptep); +pte_t pte; -if (pte_write (pte)) -ptep_xchg_lazy (mm, addr, ptep,pte_wrprotect (pte)); +if (!lazy_mmu_ptep_set_wrprotect (addr, ptep)) {
[Severity: Critical]
Can intercepting the write-protect operation here break synchronization with lockless page table walkers like GUP-fast?
During fork(), copy_pte_range() calls lazy_mmu_mode_enable_with_ptes(). When copy_present_pte() attempts to write-protect the parent's PTE by calling ptep_set_wrprotect(), the lazy MMU mode intercepts the call via __lazy_mmu_ptep_set_wrprotect() in arch/s390/mm/lazy_mmu.c:
bool __lazy_mmu_ptep_set_wrprotect(...)
{
...
pte = __ipte_range_ptep_get(range, ptep);
if (pte_write(pte)) {
pte = pte_wrprotect(pte);
__ipte_range_set_pte(range, ptep, pte);
}
return true;
}This updates the per-CPU cache but leaves the physical PTE completely valid and writable until the cache is flushed at the end of the PMD range. Because GUP-fast operates locklessly, a concurrent thread in the parent process can read the physical PTE, observe that it is still writable, and successfully take a FOLL_WRITE pin on the page.
Meanwhile, fork() proceeds, sees no pins, and shares the page with the child. Does this create a regression where the parent retains a writable GUP pin to a page shared with the child, allowing writes to corrupt the child's memory and break COW isolation?
Quoted 7 lines
arch/s390/include/asm/pgtable.h +6
-0+ pte =__ptep_get (ptep); +if (pte_write (pte)) { + pte =pte_wrprotect (pte); +ptep_xchg_lazy (mm, addr, ptep, pte); + } + } }
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Alexander Gordeev
maintainerQuoted 108 lines · On Thu, Jun 18, 2026 at 03:10:47PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Deferred PTE updates to a per-CPU cache break synchronization with lockless page table walkers like GUP-fast, allowing them to pin pages being concurrently write-protected for COW.
- [High] The lazy MMU cache bypasses thefull=1TLB flush optimization during process teardown, causing an O(N) IPTE storm.
--commit
38614c455538c6b6144011b070bbbf41513506e6
Author: Alexander Gordeev <[email protected]>s390/mm: Batch PTE updates in lazy MMU mode
This commit introduces a per-CPU cache to batch PTE updates while in lazy MMU mode. By caching PTE changes and applying them simultaneously with the IPTE instruction's "Additional Entries" feature, it reduces overall IPTE traffic.
Quoted 3 lines
arch/s390/include/asm/pgtable.h +0
-0[ ... ]
arch/s390/include/asm/pgtable.h static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, · line 1376
Quoted 10 lines
arch/s390/include/asm/pgtable.h +1
-5@@ -1259,11 +1373,13 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, {pte_t res; -if (full) { - res =ptep_get (ptep); -set_pte (ptep,__pte (_PAGE_INVALID)); - }else { - res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); +if (!lazy_mmu_ptep_get_and_clear (addr, ptep, &res)) {[Severity: High]
Does checkinglazy_mmu_ptep_get_and_clear()before the 'full' flag bypass the teardown optimization and cause an IPTE storm?During process teardown,
exit_mmap()andzap_pte_range()useptep_get_and_clear_full(..., full=1)to clear PTEs without issuing individual TLB invalidations, deferring the flush to a global teardown at the end. Iflazy_mmu_mode_enable_with_ptes()is active, this intercepts the call, writes_PAGE_INVALIDto the cache, and bypasses the if (full) path.Later, when
lazy_mmu_mode_disable()flushes the cache, it calls__invalidate_pte_range()inarch/s390/mm/lazy_mmu.c:static void
__invalidate_pte_range(...){ ... if (cpu_has_tlb_lc() && ...) __ptep_ipte_range(addr, nr_ptes - 1, ptep, IPTE_LOCAL); else __ptep_ipte_range(addr, nr_ptes - 1, ptep, IPTE_GLOBAL); ... }This unconditionally executes batched IPTE instructions for all cached PTEs. For multi-threaded processes, does this turn an O(1) TLB flush operation into an O(N) global IPTE broadcast, causing a regression in system performance during process termination?
Quoted 8 lines
arch/s390/include/asm/pgtable.h +6
-0+if (full) { + res =__ptep_get (ptep); +__set_pte (ptep,__pte (_PAGE_INVALID)); + }else { + res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); + } }page_table_check_pte_clear (mm, addr, res);[ ... ]
arch/s390/include/asm/pgtable.h static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, · line 1410
Quoted 10 lines
arch/s390/include/asm/pgtable.h +2
-3@@ -1289,10 +1405,15 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm,static inline void ptep_set_wrprotect (struct mm_struct *mm,unsigned long addr,pte_t *ptep) { -pte_t pte =ptep_get (ptep); +pte_t pte; -if (pte_write (pte)) -ptep_xchg_lazy (mm, addr, ptep,pte_wrprotect (pte)); +if (!lazy_mmu_ptep_set_wrprotect (addr, ptep)) {[Severity: Critical]
Can intercepting the write-protect operation here break synchronization with lockless page table walkers like GUP-fast?During
fork(),copy_pte_range()callslazy_mmu_mode_enable_with_ptes(). Whencopy_present_pte()attempts to write-protect the parent's PTE by callingptep_set_wrprotect(), the lazy MMU mode intercepts the call via__lazy_mmu_ptep_set_wrprotect()inarch/s390/mm/lazy_mmu.c:bool
__lazy_mmu_ptep_set_wrprotect(...){ ... pte = __ipte_range_ptep_get(range, ptep); if (pte_write(pte)) { pte = pte_wrprotect(pte); __ipte_range_set_pte(range, ptep, pte); } return true; }This updates the per-CPU cache but leaves the physical PTE completely valid and writable until the cache is flushed at the end of the PMD range. Because GUP-fast operates locklessly, a concurrent thread in the parent process can read the physical PTE, observe that it is still writable, and successfully take a
FOLL_WRITEpin on the page.
Quoted 4 lines
Meanwhile,
fork()proceeds, sees no pins, and shares the page with the child. Does this create a regression where the parent retains a writable GUP pin to a page shared with the child, allowing writes to corrupt the child's memory and break COW isolation?
If this problem existed, it would be a generic problem for all architectures that exercise the lazy mmu mode, not just for this implementation. Yet, the described scenario is avoided by using mm_struct::write_protect_seq.
mm/memory.c::copy_page_range()
if (is_cow) {
...
raw_write_seqcount_begin(&src_mm->write_protect_seq);
}
...
/* copy the range */
...
if (is_cow) {
raw_write_seqcount_end(&src_mm->write_protect_seq);
...
}mm/gup.c::gup_fast()
if (gup_flags & FOLL_PIN) {
if (!raw_seqcount_try_begin(¤t->mm->write_protect_seq, seq))
return 0;
}
...
local_irq_save(flags);
gup_fast_pgd_range(start, end, gup_flags, pages, &nr_pinned);
local_irq_restore(flags);
/*
* When pinning pages for DMA there could be a concurrent write protect
* from fork() via copy_page_range(), in this case always fail GUP-fast.
*/
if (gup_flags & FOLL_PIN) {
if (read_seqcount_retry(¤t->mm->write_protect_seq, seq)) {
gup_fast_unpin_user_pages(pages, nr_pinned);
return 0;
} else {
...
}Thus, the suggested flaw is a false positive.
Quoted 10 lines
Quoted 7 lines
arch/s390/include/asm/pgtable.h +6
-0+ pte =__ptep_get (ptep); +if (pte_write (pte)) { + pte =pte_wrprotect (pte); +ptep_xchg_lazy (mm, addr, ptep, pte); + } + } }Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Thanks!
Alexander Gordeev
maintainerQuoted 60 lines · On Thu, Jun 18, 2026 at 03:10:47PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Deferred PTE updates to a per-CPU cache break synchronization with lockless page table walkers like GUP-fast, allowing them to pin pages being concurrently write-protected for COW.
- [High] The lazy MMU cache bypasses thefull=1TLB flush optimization during process teardown, causing an O(N) IPTE storm.
--commit
38614c455538c6b6144011b070bbbf41513506e6
Author: Alexander Gordeev <[email protected]>s390/mm: Batch PTE updates in lazy MMU mode
This commit introduces a per-CPU cache to batch PTE updates while in lazy MMU mode. By caching PTE changes and applying them simultaneously with the IPTE instruction's "Additional Entries" feature, it reduces overall IPTE traffic.
Quoted 3 lines
arch/s390/include/asm/pgtable.h +0
-0[ ... ]
arch/s390/include/asm/pgtable.h static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, · line 1376
Quoted 10 lines
arch/s390/include/asm/pgtable.h +1
-5@@ -1259,11 +1373,13 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, {pte_t res; -if (full) { - res =ptep_get (ptep); -set_pte (ptep,__pte (_PAGE_INVALID)); - }else { - res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); +if (!lazy_mmu_ptep_get_and_clear (addr, ptep, &res)) {[Severity: High]
Does checkinglazy_mmu_ptep_get_and_clear()before the 'full' flag bypass the teardown optimization and cause an IPTE storm?During process teardown,
exit_mmap()andzap_pte_range()useptep_get_and_clear_full(..., full=1)to clear PTEs without issuing individual TLB invalidations, deferring the flush to a global teardown at the end. Iflazy_mmu_mode_enable_with_ptes()is active, this intercepts the call, writes_PAGE_INVALIDto the cache, and bypasses the if (full) path.Later, when
lazy_mmu_mode_disable()flushes the cache, it calls__invalidate_pte_range()inarch/s390/mm/lazy_mmu.c:static void
__invalidate_pte_range(...){ ... if (cpu_has_tlb_lc() && ...) __ptep_ipte_range(addr, nr_ptes - 1, ptep, IPTE_LOCAL); else __ptep_ipte_range(addr, nr_ptes - 1, ptep, IPTE_GLOBAL); ... }This unconditionally executes batched IPTE instructions for all cached PTEs. For multi-threaded processes, does this turn an O(1) TLB flush operation into an O(N) global IPTE broadcast, causing a regression in system performance during process termination?
Quoted 10 lines
Quoted 8 lines
arch/s390/include/asm/pgtable.h +6
-0+if (full) { + res =__ptep_get (ptep); +__set_pte (ptep,__pte (_PAGE_INVALID)); + }else { + res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); + } }page_table_check_pte_clear (mm, addr, res);[ ... ]
This is a valid concern and a solution could look like the fixup below. Yet, there is no real difference with the current version observed and therefore I want to stick with it.
arch/s390/include/asm/pgtable.h +14 -4
@@ -41,6 +41,7 @@ extern atomic_long_t direct_pages_count[PG_DIRECT_MAP_MAX];bool __lazy_mmu_ptep_test_and_clear_young (unsigned long addr,pte_t *ptep,int *res);bool __lazy_mmu_ptep_get_and_clear (unsigned long addr,pte_t *ptep,pte_t *res); +bool __lazy_mmu_ptep_get_and_clear_full (unsigned long addr,pte_t *ptep,pte_t *res);bool __lazy_mmu_ptep_modify_prot_start (unsigned long addr,pte_t *ptep,pte_t *res);bool __lazy_mmu_ptep_modify_prot_commit (unsigned long addr,pte_t *ptep,pte_t old_pte,pte_t pte);bool __lazy_mmu_ptep_set_wrprotect (unsigned long addr,pte_t *ptep);
@@ -72,6 +73,14 @@ bool lazy_mmu_ptep_get_and_clear(unsigned long addr, pte_t *ptep, pte_t *res)return __lazy_mmu_ptep_get_and_clear (addr, ptep, res); } +static inline +bool lazy_mmu_ptep_get_and_clear_full (unsigned long addr,pte_t *ptep,pte_t *res) +{ +if (!is_lazy_mmu_active ()) +return false; +return __lazy_mmu_ptep_get_and_clear_full (addr, ptep, res); +} +static inline bool lazy_mmu_ptep_modify_prot_start (unsigned long addr,pte_t *ptep,pte_t *res) {
@@ -1379,13 +1388,14 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, {pte_t res; -if (!lazy_mmu_ptep_get_and_clear (addr, ptep, &res)) { -if (full) { +if (full) { +if (!lazy_mmu_ptep_get_and_clear_full (addr, ptep, &res)) { res =__ptep_get (ptep);__set_pte (ptep,__pte (_PAGE_INVALID)); - }else { - res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); } + }else { +if (!lazy_mmu_ptep_get_and_clear (addr, ptep, &res)) + res =ptep_xchg_lazy (mm, addr, ptep,__pte (_PAGE_INVALID)); }page_table_check_pte_clear (mm, addr, res);/* At this point the reference through the mapping is still present */
arch/s390/mm/lazy_mmu.c +43 -11
80 lines not on this page · raw message
Quoted 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Thanks!
Alexander Gordeev
maintainerPATCH v4 3/4 mm/kasan: Introduce helpers for lazy MMU mode sanitizer
In reply to Alexander GordeevProvide helpers that allow architectures implement illegitimate PTE direct accesses while the lazy MMU mode is enabled, such as:
pte_t pte = *ptep; *ptep = pte;
By contrast, these would have to be:
pte_t pte = ptep_get(ptep); set_pte(ptep, pte);
The direct PTE accesses pose a real issue on s390.
--- include/linux/kasan.h | 16 ++++++++++++++++ mm/kasan/common.c | 10 ++++++++++ mm/kasan/kasan.h | 2 ++ 3 files changed, 28 insertions(+)
include/linux/kasan.h +16 -0
@@ -134,6 +134,20 @@ static __always_inline void kasan_poison_slab(struct slab *slab)__kasan_poison_slab (slab); } +void __kasan_poison_pte (pte_t *pte,int nr); +static __always_inline void kasan_poison_pte(pte_t *pte, int nr) +{ +if (kasan_enabled ()) +__kasan_poison_pte (pte, nr); +} + +void __kasan_unpoison_pte (pte_t *pte,int nr); +static __always_inline void kasan_unpoison_pte(pte_t *pte, int nr) +{ +if (kasan_enabled ()) +__kasan_unpoison_pte (pte, nr); +} +void __kasan_unpoison_new_object (struct kmem_cache *cache,void *object);/** * kasan_unpoison_new_object - Temporarily unpoison a new slab object.
@@ -414,6 +428,8 @@ static inline bool kasan_unpoison_pages(struct page *page, unsigned int order,return false; }static inline void kasan_poison_slab (struct slab *slab) {} +static inline void kasan_poison_pte (pte_t *pte,int nr) {} +static inline void kasan_unpoison_pte (pte_t *pte,int nr) {}static inline void kasan_unpoison_new_object (struct kmem_cache *cache,void *object) {} static inline void kasan_poison_new_object(struct kmem_cache *cache,
mm/kasan/common.c +10 -0
@@ -163,6 +163,16 @@ void __kasan_poison_slab(struct slab *slab) KASAN_SLAB_REDZONE, false); } +void __kasan_poison_pte (pte_t *pte,int nr) +{ +kasan_poison (pte,sizeof (*pte) * nr,KASAN_LAZY_MMU_PTE , false); +} + +void __kasan_unpoison_pte (pte_t *pte,int nr) +{ +kasan_unpoison (pte,sizeof (*pte) * nr, false); +} +void __kasan_unpoison_new_object (struct kmem_cache *cache,void *object) {kasan_unpoison (object, cache->object_size, false);
mm/kasan/kasan.h +2 -0
@@ -144,12 +144,14 @@ static inline bool kasan_requires_meta(void)#define KASAN_PAGE_REDZONE 0xFE/* redzone for kmalloc_large allocation */ #define KASAN_SLAB_REDZONE 0xFC/* redzone for slab object */ #define KASAN_SLAB_FREE 0xFB/* freed slab object */ +#define KASAN_LAZY_MMU_PTE 0xFD#define KASAN_VMALLOC_INVALID 0xF8/* inaccessible space in vmap area */ #else #define KASAN_PAGE_FREE KASAN_TAG_INVALID#define KASAN_PAGE_REDZONE KASAN_TAG_INVALID#define KASAN_SLAB_REDZONE KASAN_TAG_INVALID#define KASAN_SLAB_FREE KASAN_TAG_INVALID +#define KASAN_LAZY_MMU_PTE KASAN_TAG_INVALID#define KASAN_VMALLOC_INVALID KASAN_TAG_INVALID/* only used for SW_TAGS */ #endif
Signature · 1 line
2.53.0
[email protected]
AI reviewRe: [PATCH -next v4 3/4] mm/kasan: Introduce helpers for lazy MMU mode sanitizer
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The new KASAN_LAZY_MMU_PTE shadow value is not mapped to a bug type in the KASAN reporting…
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new KASAN_LAZY_MMU_PTE shadow value is not mapped to a bug type in the KASAN reporting logic, resulting in uninformative "unknown-crash" reports. --
commit 7d8731323b7762279e28d0aef3b1b3c457449b81
Author: Alexander Gordeev <[email protected]>
mm/kasan: Introduce helpers for lazy MMU mode sanitizer
This commit provides helpers to allow architectures to poison and unpoison PTEs during lazy MMU mode. It introduces a new KASAN shadow tag to track and catch direct PTE manipulations that improperly bypass the correct accessors.
Quoted 4 lines
mm/kasan/kasan.h +0
-0
[ ... ]
mm/kasan/kasan.h static inline bool kasan_requires_meta(void) · line 147
Quoted 5 lines
mm/kasan/kasan.h +1
-0@@ -144,12 +144,14 @@ static inline bool kasan_requires_meta(void)#define KASAN_PAGE_REDZONE 0xFE/* redzone for kmalloc_large allocation */ #define KASAN_SLAB_REDZONE 0xFC/* redzone for slab object */ #define KASAN_SLAB_FREE 0xFB/* freed slab object */ +#define KASAN_LAZY_MMU_PTE 0xFD
[Severity: Medium]
Since this adds a new shadow tag value, does get_shadow_bug_type() in mm/kasan/report_generic.c also need to be updated to handle it?
Currently, if KASAN catches a direct PTE access and reads this shadow value, it looks like it will fall through the switch statement in get_shadow_bug_type() and default to reporting an "unknown-crash".
Would adding KASAN_LAZY_MMU_PTE to the switch cases ensure we get a more descriptive bug type instead?
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
Alexander Gordeev
maintainerRe: [PATCH -next v4 3/4] mm/kasan: Introduce helpers for lazy MMU mode sanitizer
Quoted 29 lines · On Thu, Jun 18, 2026 at 03:00:48PM +0000, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newKASAN_LAZY_MMU_PTEshadow value is not mapped to a bug type in the KASAN reporting logic, resulting in uninformative "unknown-crash" reports. --commit
7d8731323b7762279e28d0aef3b1b3c457449b81
Author: Alexander Gordeev <[email protected]>mm/kasan: Introduce helpers for lazy MMU mode sanitizer
This commit provides helpers to allow architectures to poison and unpoison PTEs during lazy MMU mode. It introduces a new KASAN shadow tag to track and catch direct PTE manipulations that improperly bypass the correct accessors.
Quoted 4 lines
mm/kasan/kasan.h +0
-0[ ... ]
mm/kasan/kasan.h static inline bool kasan_requires_meta(void) · line 147
Quoted 5 lines
mm/kasan/kasan.h +1
-0@@ -144,12 +144,14 @@ static inline bool kasan_requires_meta(void)#define KASAN_PAGE_REDZONE 0xFE/* redzone for kmalloc_large allocation */ #define KASAN_SLAB_REDZONE 0xFC/* redzone for slab object */ #define KASAN_SLAB_FREE 0xFB/* freed slab object */ +#define KASAN_LAZY_MMU_PTE 0xFD[Severity: Medium]
Since this adds a new shadow tag value, doesget_shadow_bug_type()inmm/kasan/report_generic.calso need to be updated to handle it?
Quoted 6 lines
Currently, if KASAN catches a direct PTE access and reads this shadow value, it looks like it will fall through the switch statement in
get_shadow_bug_type()and default to reporting an "unknown-crash".Would adding
KASAN_LAZY_MMU_PTEto the switch cases ensure we get a more descriptive bug type instead?
This is a valid point and the fixup would be:
mm/kasan/report_generic.c +3 -0
@@ -113,6 +113,9 @@ static const char *get_shadow_bug_type(struct kasan_report_info *info)case KASAN_SLAB_FREE_META : bug_type ="slab-use-after-free" ;break ; +case KASAN_LAZY_MMU_PTE : + bug_type ="direct-pte-access" ; +break ;case KASAN_ALLOCA_LEFT :case KASAN_ALLOCA_RIGHT : bug_type ="alloca-out-of-bounds" ;
Quoted 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
Thanks!
Alexander Gordeev
maintainerPATCH v4 4/4 s390/mm: Lazy MMU mode sanitizer
In reply to Alexander GordeevDetect PTE entries access in lazy MMU mode by means other than set_pte() and ptep_get() primitives, which would be a read hazard.
The access to kasan shadow memory from ptep_get_lockless() mistakenly hits invalid access in case a concurrent lazy MMU access to the same PTE is happening. To avoid that disable instrumentation for ptep_get_lockless() altogether.
--- arch/s390/include/asm/pgtable.h | 6 ++++++ arch/s390/mm/lazy_mmu.c | 27 +++++++++++++++++++++++---- 2 files changed, 29 insertions(+), 4 deletions(-)
arch/s390/include/asm/pgtable.h +6 -0
@@ -1047,6 +1047,12 @@ static inline void set_pte(pte_t *ptep, pte_t pte)__set_pte (ptep, pte); } +#define ptep_get_lockless ptep_get_lockless +static inline __no_sanitize_address pte_t ptep_get_lockless(pte_t *ptep) +{ +return READ_ONCE (*ptep); +} +static inline pte_t __ptep_get (pte_t *ptep) {return READ_ONCE (*ptep);
arch/s390/mm/lazy_mmu.c +23 -4
@@ -63,10 +63,13 @@ static int invalidate_pte_range(struct mm_struct *mm, unsigned long addr, }static void set_pte_range (struct mm_struct *mm,unsigned long addr, -pte_t *ptep,pte_t *end,pte_t *cache) +pte_t *start,pte_t *end,pte_t *cache) { -int i, nr_ptes; +int nr_ptes, nr_total = end - start; +pte_t *ptep = start; +int i; +kasan_unpoison_pte (start, nr_total);while (ptep < end) { nr_ptes =invalidate_pte_range (mm, addr, ptep, end);
@@ -77,6 +80,7 @@ static void set_pte_range(struct mm_struct *mm, unsigned long addr, addr += nr_ptes *PAGE_SIZE ; } +kasan_poison_pte (start, nr_total); }static void enter_ipte_norange (void )
@@ -94,6 +98,7 @@ static void enter_ipte_range(struct mm_struct *mm, unsigned long addr, unsigned long end, pte_t *pte) { struct ipte_range *range; +unsigned int nr_ptes;if (!test_facility (13 ))return ;
@@ -105,6 +110,9 @@ static void enter_ipte_range(struct mm_struct *mm, range->base_addr = addr; range->base_end = end; range->base_pte = pte; + + nr_ptes = (range->base_end - range->base_addr) /PAGE_SIZE ; +kasan_poison_pte (range->base_pte, nr_ptes); }static void leave_ipte_range (void )
@@ -112,6 +120,7 @@ static void leave_ipte_range(void)pte_t *ptep, *start, *start_cache, *cache;unsigned long start_addr, addr;struct ipte_range *range; +unsigned int nr_ptes;int start_idx;if (!test_facility (13 ))
@@ -148,6 +157,9 @@ static void leave_ipte_range(void) range->end_pte =NULL ; done: + nr_ptes = (range->base_end - range->base_addr) /PAGE_SIZE ; +kasan_unpoison_pte (range->base_pte, nr_ptes); + range->mm =NULL ; range->base_addr =0 ; range->base_end =0 ;
@@ -227,10 +239,17 @@ static void __ipte_range_set_pte(struct ipte_range *range, pte_t *ptep, pte_t ptstatic pte_t __ipte_range_ptep_get (struct ipte_range *range,pte_t *ptep) {unsigned int idx = ptep - range->base_pte; +pte_t pte;lockdep_assert_preemption_disabled (); -if (pte_val (range->cache[idx]) ==PTE_POISON ) -return __ptep_get (ptep); +if (pte_val (range->cache[idx]) ==PTE_POISON ) { +kasan_unpoison_pte (ptep,1 ); + pte =__ptep_get (ptep); +kasan_poison_pte (ptep,1 ); + +return pte; + } +return range->cache[idx]; }
Signature · 1 line
2.53.0