| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/11 08:50 | flow | patch-triage |
1mArgs:null Results: {
"EnableConfigs": [
"KSM",
"TRANSPARENT_HUGEPAGE",
"MIGRATION",
"UPROBES"
],
"FocusSymbols": [
"folio_walk_start",
"break_ksm",
"find_mergeable_vma_locked",
"get_mergeable_page",
"try_to_merge_with_ksm_page",
"try_to_merge_with_zero_page",
"ksm_madvise",
"break_cow",
"split_huge_pages_pid"
],
"KMSANReasoning": "The patch refactors page walk locking and transitions KSM from mmap_read_lock to per-VMA read locking (vma_start_read_unlocked/vma_end_read) with lock verification in folio_walk_start(). All local instances of `struct folio_walk` across the codebase are explicitly initialized with designated initializers (`struct folio_walk fw = { .walk_lock = ... };`), which zero-initializes the remaining fields as per C semantics. No kernel buffers or structures are copied to userspace, no uninitialized memory is read or branched upon, and the patch primarily alters locking/synchronization semantics (which are monitored by LOCKDEP and KASAN). Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies page walking and KSM locking semantics across core memory management (pagewalk, KSM, THP, migration, rmap, uprobes). It introduces per-VMA read locking (PGWALK_VMA_RDLOCK_VERIFY via vma_start_read_unlocked) to KSM routines, dynamically alters break_ksm_ops walk locking, and adds locking validation checks/assertions in folio_walk_start. These changes alter locking invariants and state management in reachable core mm code.",
"WorthFuzzing": true
} |
| 1/1 | 2026/09/11 08:50 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit ac265eb0d7b755f668cc5b0ecc34f057a6ca756f\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Fri Sep 11 08:50:22 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c\nindex 46d828926009b..968f128a52320 100644\n--- a/arch/s390/mm/fault.c\n+++ b/arch/s390/mm/fault.c\n@@ -412,7 +412,9 @@ __context_unsafe(/* folio_walk_end() not instrumented */)\n \tunsigned long addr = get_fault_address(regs);\n \tstruct mm_struct *mm = current-\u003emm;\n \tstruct vm_area_struct *vma;\n-\tstruct folio_walk fw;\n+\tstruct folio_walk fw = {\n+\t\t.walk_lock = PGWALK_RDLOCK,\n+\t};\n \tstruct folio *folio;\n \tint rc;\n \ndiff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h\nindex b41d7265c01bc..455428eaf1fc0 100644\n--- a/include/linux/pagewalk.h\n+++ b/include/linux/pagewalk.h\n@@ -183,8 +183,8 @@ struct folio_walk {\n \t\tpmd_t pmd;\n \t};\n \t/* private */\n-\tstruct vm_area_struct *vma;\n \tspinlock_t *ptl;\n+\tenum page_walk_lock walk_lock;\n };\n \n struct folio *folio_walk_start(struct folio_walk *fw,\ndiff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c\nindex 7709ea8824778..054fdcb521366 100644\n--- a/kernel/events/uprobes.c\n+++ b/kernel/events/uprobes.c\n@@ -507,7 +507,9 @@ int uprobe_write(struct arch_uprobe *auprobe, struct vm_area_struct *vma,\n \tint ret, ref_ctr_updated = 0;\n \tunsigned int gup_flags = FOLL_FORCE;\n \tstruct mmu_notifier_range range;\n-\tstruct folio_walk fw;\n+\tstruct folio_walk fw = {\n+\t\t.walk_lock = PGWALK_RDLOCK,\n+\t};\n \tstruct folio *folio;\n \tstruct page *page;\n \ndiff --git a/mm/huge_memory.c b/mm/huge_memory.c\nindex 30b7c63b0e359..d0447b6ae6e41 100644\n--- a/mm/huge_memory.c\n+++ b/mm/huge_memory.c\n@@ -4810,7 +4810,9 @@ static int split_huge_pages_pid(int pid, unsigned long vaddr_start,\n \t */\n \tfor (addr = vaddr_start; addr \u003c vaddr_end; addr += PAGE_SIZE) {\n \t\tstruct vm_area_struct *vma = vma_lookup(mm, addr);\n-\t\tstruct folio_walk fw;\n+\t\tstruct folio_walk fw = {\n+\t\t\t.walk_lock = PGWALK_RDLOCK,\n+\t\t};\n \t\tstruct folio *folio;\n \t\tstruct address_space *mapping;\n \t\tunsigned int target_order = new_order;\ndiff --git a/mm/ksm.c b/mm/ksm.c\nindex 624f37975e129..1d85769ec7dbe 100644\n--- a/mm/ksm.c\n+++ b/mm/ksm.c\n@@ -660,16 +660,11 @@ static int break_ksm_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned long en\n \treturn found;\n }\n \n-static const struct mm_walk_ops break_ksm_ops = {\n+static struct mm_walk_ops break_ksm_ops = {\n \t.pmd_entry = break_ksm_pmd_entry,\n \t.walk_lock = PGWALK_RDLOCK,\n };\n \n-static const struct mm_walk_ops break_ksm_lock_vma_ops = {\n-\t.pmd_entry = break_ksm_pmd_entry,\n-\t.walk_lock = PGWALK_WRLOCK,\n-};\n-\n /*\n * Though it's very tempting to unmerge rmap_items from stable tree rather\n * than check every pte of a given vma, the locking doesn't quite work for\n@@ -696,11 +691,11 @@ static const struct mm_walk_ops break_ksm_lock_vma_ops = {\n * protection keys here anyway.\n */\n static int break_ksm(struct vm_area_struct *vma, unsigned long addr,\n-\t\tunsigned long end, bool lock_vma)\n+\t\tunsigned long end, enum page_walk_lock walk_lock)\n {\n \tvm_fault_t ret = 0;\n-\tconst struct mm_walk_ops *ops = lock_vma ?\n-\t\t\t\t\u0026break_ksm_lock_vma_ops : \u0026break_ksm_ops;\n+\tstruct mm_walk_ops *ops = \u0026break_ksm_ops;\n+\tops-\u003ewalk_lock = walk_lock;\n \n \tdo {\n \t\tint ksm_page;\n@@ -770,15 +765,36 @@ static bool vma_ksm_compatible(struct vm_area_struct *vma)\n \treturn ksm_compatible(vma-\u003evm_file, vma-\u003eflags);\n }\n \n-static struct vm_area_struct *find_mergeable_vma(struct mm_struct *mm,\n-\t\tunsigned long addr)\n+/**\n+ * find_mergeable_vma_locked() - Find the VMA covering 'address' which is\n+ * VM_MERGEABLE and read-lock it by per-VMA locks. Please use vma_end_read()\n+ * to unlock vma after finishing reading the VMA (non-NULL).\n+ *\n+ * Return: If a VMA exists which spans @address, return that VMA, read-locked.\n+ * If no VMA is mapped there or, very unlikely, a reference count overflow\n+ * occurred, return NULL, and no read-locked.\n+ *\n+ * IMPORTANT: If a VMA exists but is not VM_MERGEABLE or has no anon_vma,\n+ * this function releases the per-VMA read lock before returning NULL.\n+ * Callers must NOT call vma_end_read() on a NULL return value.\n+ */\n+static struct vm_area_struct *find_mergeable_vma_locked(struct mm_struct *mm,\n+\t\tunsigned long address)\n {\n \tstruct vm_area_struct *vma;\n+\n \tif (ksm_test_exit(mm))\n \t\treturn NULL;\n-\tvma = vma_lookup(mm, addr);\n-\tif (!vma || !(vma-\u003evm_flags \u0026 VM_MERGEABLE) || !vma-\u003eanon_vma)\n+\n+\tvma = vma_start_read_unlocked(mm, address);\n+\tif (!vma)\n+\t\treturn NULL;\n+\n+\tif (!(vma-\u003evm_flags \u0026 VM_MERGEABLE) || !vma-\u003eanon_vma) {\n+\t\tvma_end_read(vma);\n \t\treturn NULL;\n+\t}\n+\n \treturn vma;\n }\n \n@@ -804,11 +820,12 @@ static void break_cow(struct ksm_rmap_item *rmap_item)\n \t */\n \trmap_item-\u003elinear_page_index = 0;\n \n-\tmmap_read_lock(mm);\n-\tvma = find_mergeable_vma(mm, addr);\n-\tif (vma)\n-\t\tbreak_ksm(vma, addr, addr + PAGE_SIZE, false);\n-\tmmap_read_unlock(mm);\n+\tvma = find_mergeable_vma_locked(mm, addr);\n+\tif (!vma)\n+\t\treturn;\n+\n+\tbreak_ksm(vma, addr, addr + PAGE_SIZE, PGWALK_VMA_RDLOCK_VERIFY);\n+\tvma_end_read(vma);\n }\n \n static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)\n@@ -817,13 +834,14 @@ static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)\n \tunsigned long addr = rmap_item-\u003eaddress;\n \tstruct vm_area_struct *vma;\n \tstruct page *page = NULL;\n-\tstruct folio_walk fw;\n \tstruct folio *folio;\n+\tstruct folio_walk fw = {\n+\t\t.walk_lock = PGWALK_VMA_RDLOCK_VERIFY,\n+\t};\n \n-\tmmap_read_lock(mm);\n-\tvma = find_mergeable_vma(mm, addr);\n+\tvma = find_mergeable_vma_locked(mm, addr);\n \tif (!vma)\n-\t\tgoto out;\n+\t\treturn NULL;\n \n \tfolio = folio_walk_start(\u0026fw, vma, addr, 0);\n \tif (folio) {\n@@ -834,12 +852,12 @@ static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)\n \t\t}\n \t\tfolio_walk_end(\u0026fw, vma);\n \t}\n-out:\n+\n \tif (page) {\n \t\tflush_anon_page(vma, page, addr);\n \t\tflush_dcache_page(page);\n \t}\n-\tmmap_read_unlock(mm);\n+\tvma_end_read(vma);\n \treturn page;\n }\n \n@@ -1243,7 +1261,7 @@ static int unmerge_and_remove_all_rmap_items(void)\n \t\tfor_each_vma(vmi, vma) {\n \t\t\tif (!(vma-\u003evm_flags \u0026 VM_MERGEABLE) || !vma-\u003eanon_vma)\n \t\t\t\tcontinue;\n-\t\t\terr = break_ksm(vma, vma-\u003evm_start, vma-\u003evm_end, false);\n+\t\t\terr = break_ksm(vma, vma-\u003evm_start, vma-\u003evm_end, PGWALK_RDLOCK);\n \t\t\tif (err)\n \t\t\t\tgoto error;\n \t\t}\n@@ -1571,14 +1589,14 @@ static int try_to_merge_with_zero_page(struct ksm_rmap_item *rmap_item,\n \tif (ksm_use_zero_pages \u0026\u0026 (rmap_item-\u003eoldchecksum == zero_checksum)) {\n \t\tstruct vm_area_struct *vma;\n \n-\t\tmmap_read_lock(mm);\n-\t\tvma = find_mergeable_vma(mm, rmap_item-\u003eaddress);\n+\t\tvma = find_mergeable_vma_locked(mm, rmap_item-\u003eaddress);\n \t\tif (vma) {\n \t\t\terr = try_to_merge_one_page(vma, page,\n \t\t\t\t\tZERO_PAGE(rmap_item-\u003eaddress));\n \t\t\ttrace_ksm_merge_one_page(\n \t\t\t\tpage_to_pfn(ZERO_PAGE(rmap_item-\u003eaddress)),\n \t\t\t\trmap_item, mm, err);\n+\t\t\tvma_end_read(vma);\n \t\t} else {\n \t\t\t/*\n \t\t\t * If the vma is out of date, we do not need to\n@@ -1586,7 +1604,6 @@ static int try_to_merge_with_zero_page(struct ksm_rmap_item *rmap_item,\n \t\t\t */\n \t\t\terr = 0;\n \t\t}\n-\t\tmmap_read_unlock(mm);\n \t}\n \n \treturn err;\n@@ -1605,10 +1622,9 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,\n \tstruct vm_area_struct *vma;\n \tint err = -EFAULT;\n \n-\tmmap_read_lock(mm);\n-\tvma = find_mergeable_vma(mm, rmap_item-\u003eaddress);\n+\tvma = find_mergeable_vma_locked(mm, rmap_item-\u003eaddress);\n \tif (!vma)\n-\t\tgoto out;\n+\t\tgoto out_trace;\n \n \terr = try_to_merge_one_page(vma, page, kpage);\n \tif (err)\n@@ -1628,7 +1644,8 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,\n \trmap_item-\u003elinear_page_index = linear_anon_page_index(vma, rmap_item-\u003eaddress);\n \tget_anon_vma(vma-\u003eanon_vma);\n out:\n-\tmmap_read_unlock(mm);\n+\tvma_end_read(vma);\n+out_trace:\n \ttrace_ksm_merge_with_ksm_page(kpage, page_to_pfn(kpage ? kpage : page),\n \t\t\t\trmap_item, mm, err);\n \treturn err;\n@@ -2883,7 +2900,7 @@ static int __ksm_del_vma(struct vm_area_struct *vma)\n \t\treturn 0;\n \n \tif (vma-\u003eanon_vma) {\n-\t\terr = break_ksm(vma, vma-\u003evm_start, vma-\u003evm_end, true);\n+\t\terr = break_ksm(vma, vma-\u003evm_start, vma-\u003evm_end, PGWALK_WRLOCK);\n \t\tif (err)\n \t\t\treturn err;\n \t}\n@@ -3035,7 +3052,7 @@ int ksm_madvise(struct vm_area_struct *vma, unsigned long start,\n \t\t\treturn 0;\t\t/* just ignore the advice */\n \n \t\tif (vma-\u003eanon_vma) {\n-\t\t\terr = break_ksm(vma, start, end, true);\n+\t\t\terr = break_ksm(vma, start, end, PGWALK_WRLOCK);\n \t\t\tif (err)\n \t\t\t\treturn err;\n \t\t}\ndiff --git a/mm/migrate.c b/mm/migrate.c\nindex a369d0c95c386..2e078c1e1b9a6 100644\n--- a/mm/migrate.c\n+++ b/mm/migrate.c\n@@ -2302,7 +2302,9 @@ static int add_folio_for_migration(struct mm_struct *mm, const void __user *p,\n \t\tint node, struct list_head *pagelist, bool migrate_all)\n {\n \tstruct vm_area_struct *vma;\n-\tstruct folio_walk fw;\n+\tstruct folio_walk fw = {\n+\t\t.walk_lock = PGWALK_RDLOCK,\n+\t};\n \tstruct folio *folio;\n \tunsigned long addr;\n \tint err = -EFAULT;\n@@ -2464,7 +2466,9 @@ static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages,\n \tfor (i = 0; i \u003c nr_pages; i++) {\n \t\tunsigned long addr = (unsigned long)(*pages);\n \t\tstruct vm_area_struct *vma;\n-\t\tstruct folio_walk fw;\n+\t\tstruct folio_walk fw = {\n+\t\t\t.walk_lock = PGWALK_RDLOCK,\n+\t\t};\n \t\tstruct folio *folio;\n \t\tint err = -EFAULT;\n \ndiff --git a/mm/pagewalk.c b/mm/pagewalk.c\nindex 7411702a37f58..8eb29fba20ad9 100644\n--- a/mm/pagewalk.c\n+++ b/mm/pagewalk.c\n@@ -910,7 +910,15 @@ struct folio *folio_walk_start(struct folio_walk *fw,\n \tpgd_t *pgdp;\n \tp4d_t *p4dp;\n \n-\tmmap_assert_locked(vma-\u003evm_mm);\n+\t/*\n+\t * Other locking modes except for mmap or vma read locking are not\n+\t * expected.\n+\t */\n+\tif (fw-\u003ewalk_lock != PGWALK_RDLOCK \u0026\u0026 fw-\u003ewalk_lock != PGWALK_VMA_RDLOCK_VERIFY)\n+\t\tWARN_ONCE(1, \"walk_lock is not expected!\\n\");\n+\tprocess_mm_walk_lock(vma-\u003evm_mm, fw-\u003ewalk_lock);\n+\tprocess_vma_walk_lock(vma, fw-\u003ewalk_lock);\n+\n \tvma_pgtable_walk_begin(vma);\n \n \tif (WARN_ON_ONCE(addr \u003c vma-\u003evm_start || addr \u003e= vma-\u003evm_end))\ndiff --git a/mm/rmap.c b/mm/rmap.c\nindex 5332c52909be1..0ca24bcf95703 100644\n--- a/mm/rmap.c\n+++ b/mm/rmap.c\n@@ -2871,7 +2871,9 @@ struct page *make_device_exclusive(struct mm_struct *mm, unsigned long addr,\n \tstruct mmu_notifier_range range;\n \tstruct folio *folio, *fw_folio;\n \tstruct vm_area_struct *vma;\n-\tstruct folio_walk fw;\n+\tstruct folio_walk fw = {\n+\t\t.walk_lock = PGWALK_RDLOCK,\n+\t};\n \tstruct page *page;\n \tswp_entry_t entry;\n \tpte_t swp_pte;\n"
} |
| 2/1 | 2026/09/11 08:50 | agent | patch-evaluator |
1mModel:core Args: null Results: {
"EnableConfigs": [
"KSM",
"TRANSPARENT_HUGEPAGE",
"MIGRATION",
"UPROBES"
],
"FocusSymbols": [
"folio_walk_start",
"break_ksm",
"find_mergeable_vma_locked",
"get_mergeable_page",
"try_to_merge_with_ksm_page",
"try_to_merge_with_zero_page",
"ksm_madvise",
"break_cow",
"split_huge_pages_pid"
],
"Reasoning": "The patch modifies page walking and KSM locking semantics across core memory management (pagewalk, KSM, THP, migration, rmap, uprobes). It introduces per-VMA read locking (PGWALK_VMA_RDLOCK_VERIFY via vma_start_read_unlocked) to KSM routines, dynamically alters break_ksm_ops walk locking, and adds locking validation checks/assertions in folio_walk_start. These changes alter locking invariants and state management in reachable core mm code.",
"WorthFuzzing": true
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit ac265eb0d7b755f668cc5b0ecc34f057a6ca756f
Author: syz-cluster <triage@syzkaller.com>
Date: Fri Sep 11 08:50:22 2026 +0000
syz-cluster: applied patch under review
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 46d828926009b..968f128a52320 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -412,7 +412,9 @@ __context_unsafe(/* folio_walk_end() not instrumented */)
unsigned long addr = get_fault_address(regs);
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
int rc;
diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
index b41d7265c01bc..455428eaf1fc0 100644
--- a/include/linux/pagewalk.h
+++ b/include/linux/pagewalk.h
@@ -183,8 +183,8 @@ struct folio_walk {
pmd_t pmd;
};
/* private */
- struct vm_area_struct *vma;
spinlock_t *ptl;
+ enum page_walk_lock walk_lock;
};
struct folio *folio_walk_start(struct folio_walk *fw,
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 7709ea8824778..054fdcb521366 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -507,7 +507,9 @@ int uprobe_write(struct arch_uprobe *auprobe, struct vm_area_struct *vma,
int ret, ref_ctr_updated = 0;
unsigned int gup_flags = FOLL_FORCE;
struct mmu_notifier_range range;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
struct page *page;
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 30b7c63b0e359..d0447b6ae6e41 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -4810,7 +4810,9 @@ static int split_huge_pages_pid(int pid, unsigned long vaddr_start,
*/
for (addr = vaddr_start; addr < vaddr_end; addr += PAGE_SIZE) {
struct vm_area_struct *vma = vma_lookup(mm, addr);
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
struct address_space *mapping;
unsigned int target_order = new_order;
diff --git a/mm/ksm.c b/mm/ksm.c
index 624f37975e129..1d85769ec7dbe 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -660,16 +660,11 @@ static int break_ksm_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned long en
return found;
}
-static const struct mm_walk_ops break_ksm_ops = {
+static struct mm_walk_ops break_ksm_ops = {
.pmd_entry = break_ksm_pmd_entry,
.walk_lock = PGWALK_RDLOCK,
};
-static const struct mm_walk_ops break_ksm_lock_vma_ops = {
- .pmd_entry = break_ksm_pmd_entry,
- .walk_lock = PGWALK_WRLOCK,
-};
-
/*
* Though it's very tempting to unmerge rmap_items from stable tree rather
* than check every pte of a given vma, the locking doesn't quite work for
@@ -696,11 +691,11 @@ static const struct mm_walk_ops break_ksm_lock_vma_ops = {
* protection keys here anyway.
*/
static int break_ksm(struct vm_area_struct *vma, unsigned long addr,
- unsigned long end, bool lock_vma)
+ unsigned long end, enum page_walk_lock walk_lock)
{
vm_fault_t ret = 0;
- const struct mm_walk_ops *ops = lock_vma ?
- &break_ksm_lock_vma_ops : &break_ksm_ops;
+ struct mm_walk_ops *ops = &break_ksm_ops;
+ ops->walk_lock = walk_lock;
do {
int ksm_page;
@@ -770,15 +765,36 @@ static bool vma_ksm_compatible(struct vm_area_struct *vma)
return ksm_compatible(vma->vm_file, vma->flags);
}
-static struct vm_area_struct *find_mergeable_vma(struct mm_struct *mm,
- unsigned long addr)
+/**
+ * find_mergeable_vma_locked() - Find the VMA covering 'address' which is
+ * VM_MERGEABLE and read-lock it by per-VMA locks. Please use vma_end_read()
+ * to unlock vma after finishing reading the VMA (non-NULL).
+ *
+ * Return: If a VMA exists which spans @address, return that VMA, read-locked.
+ * If no VMA is mapped there or, very unlikely, a reference count overflow
+ * occurred, return NULL, and no read-locked.
+ *
+ * IMPORTANT: If a VMA exists but is not VM_MERGEABLE or has no anon_vma,
+ * this function releases the per-VMA read lock before returning NULL.
+ * Callers must NOT call vma_end_read() on a NULL return value.
+ */
+static struct vm_area_struct *find_mergeable_vma_locked(struct mm_struct *mm,
+ unsigned long address)
{
struct vm_area_struct *vma;
+
if (ksm_test_exit(mm))
return NULL;
- vma = vma_lookup(mm, addr);
- if (!vma || !(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
+
+ vma = vma_start_read_unlocked(mm, address);
+ if (!vma)
+ return NULL;
+
+ if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma) {
+ vma_end_read(vma);
return NULL;
+ }
+
return vma;
}
@@ -804,11 +820,12 @@ static void break_cow(struct ksm_rmap_item *rmap_item)
*/
rmap_item->linear_page_index = 0;
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, addr);
- if (vma)
- break_ksm(vma, addr, addr + PAGE_SIZE, false);
- mmap_read_unlock(mm);
+ vma = find_mergeable_vma_locked(mm, addr);
+ if (!vma)
+ return;
+
+ break_ksm(vma, addr, addr + PAGE_SIZE, PGWALK_VMA_RDLOCK_VERIFY);
+ vma_end_read(vma);
}
static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)
@@ -817,13 +834,14 @@ static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)
unsigned long addr = rmap_item->address;
struct vm_area_struct *vma;
struct page *page = NULL;
- struct folio_walk fw;
struct folio *folio;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_VMA_RDLOCK_VERIFY,
+ };
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, addr);
+ vma = find_mergeable_vma_locked(mm, addr);
if (!vma)
- goto out;
+ return NULL;
folio = folio_walk_start(&fw, vma, addr, 0);
if (folio) {
@@ -834,12 +852,12 @@ static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)
}
folio_walk_end(&fw, vma);
}
-out:
+
if (page) {
flush_anon_page(vma, page, addr);
flush_dcache_page(page);
}
- mmap_read_unlock(mm);
+ vma_end_read(vma);
return page;
}
@@ -1243,7 +1261,7 @@ static int unmerge_and_remove_all_rmap_items(void)
for_each_vma(vmi, vma) {
if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
continue;
- err = break_ksm(vma, vma->vm_start, vma->vm_end, false);
+ err = break_ksm(vma, vma->vm_start, vma->vm_end, PGWALK_RDLOCK);
if (err)
goto error;
}
@@ -1571,14 +1589,14 @@ static int try_to_merge_with_zero_page(struct ksm_rmap_item *rmap_item,
if (ksm_use_zero_pages && (rmap_item->oldchecksum == zero_checksum)) {
struct vm_area_struct *vma;
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, rmap_item->address);
+ vma = find_mergeable_vma_locked(mm, rmap_item->address);
if (vma) {
err = try_to_merge_one_page(vma, page,
ZERO_PAGE(rmap_item->address));
trace_ksm_merge_one_page(
page_to_pfn(ZERO_PAGE(rmap_item->address)),
rmap_item, mm, err);
+ vma_end_read(vma);
} else {
/*
* If the vma is out of date, we do not need to
@@ -1586,7 +1604,6 @@ static int try_to_merge_with_zero_page(struct ksm_rmap_item *rmap_item,
*/
err = 0;
}
- mmap_read_unlock(mm);
}
return err;
@@ -1605,10 +1622,9 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,
struct vm_area_struct *vma;
int err = -EFAULT;
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, rmap_item->address);
+ vma = find_mergeable_vma_locked(mm, rmap_item->address);
if (!vma)
- goto out;
+ goto out_trace;
err = try_to_merge_one_page(vma, page, kpage);
if (err)
@@ -1628,7 +1644,8 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,
rmap_item->linear_page_index = linear_anon_page_index(vma, rmap_item->address);
get_anon_vma(vma->anon_vma);
out:
- mmap_read_unlock(mm);
+ vma_end_read(vma);
+out_trace:
trace_ksm_merge_with_ksm_page(kpage, page_to_pfn(kpage ? kpage : page),
rmap_item, mm, err);
return err;
@@ -2883,7 +2900,7 @@ static int __ksm_del_vma(struct vm_area_struct *vma)
return 0;
if (vma->anon_vma) {
- err = break_ksm(vma, vma->vm_start, vma->vm_end, true);
+ err = break_ksm(vma, vma->vm_start, vma->vm_end, PGWALK_WRLOCK);
if (err)
return err;
}
@@ -3035,7 +3052,7 @@ int ksm_madvise(struct vm_area_struct *vma, unsigned long start,
return 0; /* just ignore the advice */
if (vma->anon_vma) {
- err = break_ksm(vma, start, end, true);
+ err = break_ksm(vma, start, end, PGWALK_WRLOCK);
if (err)
return err;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index a369d0c95c386..2e078c1e1b9a6 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2302,7 +2302,9 @@ static int add_folio_for_migration(struct mm_struct *mm, const void __user *p,
int node, struct list_head *pagelist, bool migrate_all)
{
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
unsigned long addr;
int err = -EFAULT;
@@ -2464,7 +2466,9 @@ static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages,
for (i = 0; i < nr_pages; i++) {
unsigned long addr = (unsigned long)(*pages);
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
int err = -EFAULT;
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index 7411702a37f58..8eb29fba20ad9 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -910,7 +910,15 @@ struct folio *folio_walk_start(struct folio_walk *fw,
pgd_t *pgdp;
p4d_t *p4dp;
- mmap_assert_locked(vma->vm_mm);
+ /*
+ * Other locking modes except for mmap or vma read locking are not
+ * expected.
+ */
+ if (fw->walk_lock != PGWALK_RDLOCK && fw->walk_lock != PGWALK_VMA_RDLOCK_VERIFY)
+ WARN_ONCE(1, "walk_lock is not expected!\n");
+ process_mm_walk_lock(vma->vm_mm, fw->walk_lock);
+ process_vma_walk_lock(vma, fw->walk_lock);
+
vma_pgtable_walk_begin(vma);
if (WARN_ON_ONCE(addr < vma->vm_start || addr >= vma->vm_end))
diff --git a/mm/rmap.c b/mm/rmap.c
index 5332c52909be1..0ca24bcf95703 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -2871,7 +2871,9 @@ struct page *make_device_exclusive(struct mm_struct *mm, unsigned long addr,
struct mmu_notifier_range range;
struct folio *folio, *fw_folio;
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct page *page;
swp_entry_t entry;
pte_t swp_pte;
|
| 3/2 | 2026/09/11 08:50 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 7249 output: 30 thoughts: 714 Thoughts: **Fuzzing Suitability Analysis** Okay, let's break this down. The question is whether this patch series is a good candidate for syzkaller fuzzing. My initial impression is that there are some red flags here that make this a potentially fertile ground for fuzzing. The patch touches a bunch of core memory management files: `arch/s390/mm/fault.c`, `include/linux/pagewalk.h`, `kernel/events/uprobes.c`, `mm/huge_memory.c`, `mm/ksm.c`, `mm/migrate.c`, `mm/pagewalk.c`, and `mm/rmap.c`. That's a wide range, indicating significant changes in how the kernel handles memory. Always a good sign for fuzzing, as it increases the potential attack surface. Now, let's get into the details: The most interesting thing is the change in `include/linux/pagewalk.h` with the introduction of `enum page_walk_lock walk_lock;` within `struct folio_walk`. This strongly indicates changes to the locking strategy during page walks, which could easily lead to concurrency issues and race conditions, something syzkaller excels at finding. The modifications in `mm/pagewalk.c` with the `folio_walk_start` function and the added checks on `fw->walk_lock` are very relevant. The `WARN_ONCE` suggests the code is *expecting* specific locking behavior, and any deviation could trigger errors. The checks on the enum and the calls to `process_mm_walk_lock` and `process_vma_walk_lock` further reinforce this. And here's the real kicker: `mm/ksm.c` has a *very* concerning change. The modification of `break_ksm_ops` to a mutable global struct and the direct assignment of `ops->walk_lock = walk_lock;` inside `break_ksm()` is almost certainly a data race! This is the kind of subtle concurrency bug that is incredibly difficult to detect manually but syzkaller should find quickly. The fact that the patch is modifying a static, const object makes this even more concerning. This is a very compelling reason to prioritize fuzzing this patch. The introduction of per-VMA locking in a number of KSM functions (`find_mergeable_vma_locked`, etc.) supports that this is a complex concurrency issue. I'm now going to use grep and read-file, but overall, given the changes to KSM, the altered locking, and the introduction of a potential data race, this patch series is *highly* suspectible to concurrency bugs and is an excellent candidate for fuzzing with syzkaller. The probability of finding interesting bugs is quite high. |
| 4/2 | 2026/09/11 08:50 | tool | grepper |
0mArgs:{
"Expression": "break_ksm",
"PathPrefix": "mm/ksm.c"
}Results: {
"Output": "mm/ksm.c=611=static inline bool ksm_test_exit(struct mm_struct *mm)\n--\nmm/ksm.c-615-\nmm/ksm.c:616:static int break_ksm_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned long end,\nmm/ksm.c-617-\t\t\tstruct mm_walk *walk)\n--\nmm/ksm.c-662-\nmm/ksm.c:663:static struct mm_walk_ops break_ksm_ops = {\nmm/ksm.c:664:\t.pmd_entry = break_ksm_pmd_entry,\nmm/ksm.c-665-\t.walk_lock = PGWALK_RDLOCK,\n--\nmm/ksm.c-680- *\nmm/ksm.c:681: * We use break_ksm to break COW on a ksm page by triggering unsharing,\nmm/ksm.c-682- * such that the ksm page will get replaced by an exclusive anonymous page.\n--\nmm/ksm.c-692- */\nmm/ksm.c:693:static int break_ksm(struct vm_area_struct *vma, unsigned long addr,\nmm/ksm.c-694-\t\tunsigned long end, enum page_walk_lock walk_lock)\n--\nmm/ksm.c-696-\tvm_fault_t ret = 0;\nmm/ksm.c:697:\tstruct mm_walk_ops *ops = \u0026break_ksm_ops;\nmm/ksm.c-698-\tops-\u003ewalk_lock = walk_lock;\n--\nmm/ksm.c=806=static void break_cow(struct ksm_rmap_item *rmap_item)\n--\nmm/ksm.c-826-\nmm/ksm.c:827:\tbreak_ksm(vma, addr, addr + PAGE_SIZE, PGWALK_VMA_RDLOCK_VERIFY);\nmm/ksm.c-828-\tvma_end_read(vma);\n--\nmm/ksm.c=1233=static int unmerge_and_remove_all_rmap_items(void)\n--\nmm/ksm.c-1263-\t\t\t\tcontinue;\nmm/ksm.c:1264:\t\t\terr = break_ksm(vma, vma-\u003evm_start, vma-\u003evm_end, PGWALK_RDLOCK);\nmm/ksm.c-1265-\t\t\tif (err)\n--\nmm/ksm.c=2895=static int __ksm_del_vma(struct vm_area_struct *vma)\n--\nmm/ksm.c-2902-\tif (vma-\u003eanon_vma) {\nmm/ksm.c:2903:\t\terr = break_ksm(vma, vma-\u003evm_start, vma-\u003evm_end, PGWALK_WRLOCK);\nmm/ksm.c-2904-\t\tif (err)\n--\nmm/ksm.c=3028=int ksm_madvise(struct vm_area_struct *vma, unsigned long start,\n--\nmm/ksm.c-3054-\t\tif (vma-\u003eanon_vma) {\nmm/ksm.c:3055:\t\t\terr = break_ksm(vma, start, end, PGWALK_WRLOCK);\nmm/ksm.c-3056-\t\t\tif (err)\n--\nmm/ksm.c=3432=static int ksm_memory_callback(struct notifier_block *self,\n--\nmm/ksm.c-3442-\t\t * it is unsafe for them to touch the stable tree at this time.\nmm/ksm.c:3443:\t\t * But break_ksm(), rmap lookups and other entry points\nmm/ksm.c-3444-\t\t * which do not need the ksm_thread_mutex are all safe.\n"
} |
| 5/2 | 2026/09/11 08:50 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 9618 output: 25 thoughts: 234 Thoughts: **My Assessment of the Codebase for Fuzzing** Okay, this is serious! We're talking core memory management code here – the stuff that *really* matters. Let's break this down systematically. The guidelines clearly state that *reachability* is the most important factor in determining if this is a good candidate for fuzzing, and it looks promising: We're dealing with modifications in crucial files: `mm/ksm.c`, `mm/pagewalk.c`, `mm/huge_memory.c`, `mm/migrate.c`, `mm/rmap.c`, and `kernel/events/uprobes.c`. Good, this looks reachable in standard environments like QEMU and Google Compute Engine (on amd64), which is ideal for this kind of work. The patch introduces locking changes in KSM and pagewalk—things like the `PGWALK_VMA_RDLOCK_VERIFY`, the `find_mergeable_vma_locked` function, and folio_walk_start assertions. These are classic areas where subtle concurrency bugs can hide, making it a prime target. Absolutely, this is *definitely* worth fuzzing! The `WorthFuzzing: true` marker confirms that. Now, let's get into the details. I need to figure out the minimal set of configurations required to exercise all this code. Specifically, what kernel configurations need to be enabled for KSM, pagewalk, folio_walk, uprobes, migrate, and huge_memory? I'll need to dig into the `Kconfig` files associated with `mm/ksm.c`, `mm/pagewalk.c`, and so on to determine that. This is the next step to creating a testing environment. |
| 6/2 | 2026/09/11 08:50 | tool | grepper |
0mArgs:{
"Expression": "config KSM",
"PathPrefix": "mm/"
}Results: {
"Output": "mm/Kconfig=723=config MMU_NOTIFIER\n--\nmm/Kconfig-726-\nmm/Kconfig:727:config KSM\nmm/Kconfig-728-\tbool \"Enable KSM for page merging\"\n"
} |
| 7/2 | 2026/09/11 08:50 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 10321 output: 27 thoughts: 24 Thoughts: Here's my take on those thoughts, tailored for an expert audience: **Diving into the Build Process of KSM and Pagewalk** Okay, so I need to understand the build configuration for `ksm.c` and `pagewalk.c`. Where's the logical starting point for understanding how these pieces are compiled and linked? Right, the `Makefile` in the `mm` directory. That's usually the place where the core build rules for memory management components are defined. I need to quickly determine the compiler flags, any specific object file dependencies, and how these modules integrate within the larger build process. Time to crack open that `mm/Makefile` and see what's what. Let's see if I can spot any interesting tricks or optimization strategies employed there. |
| 8/2 | 2026/09/11 08:50 | tool | grepper |
0mArgs:{
"Expression": "ksm.o",
"PathPrefix": "mm/Makefile"
}Results: {
"Output": "mm/Makefile=90=obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o\nmm/Makefile:91:obj-$(CONFIG_KSM) += ksm.o\nmm/Makefile-92-obj-$(CONFIG_PAGE_POISONING) += page_poison.o\n"
} |
| 9/2 | 2026/09/11 08:50 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 10620 output: 39 thoughts: 29 Thoughts: Okay, here's my take on those potential areas for investigation: **My Initial Assessment of Target Modules** Alright, time to dig in. My gut feeling tells me these are likely key areas that need further scrutiny based on the current system behavior. Let's start by zeroing in on `pagewalk.o`, `huge_memory.o`, `migrate.o`, and `uprobes.o`. Considering my expertise, I'm expecting these modules to reveal some interesting findings related to virtual memory management, potential bottlenecks in large page handling, live migration complexities, and the possible overhead of user-space probing. I want to understand how they are interacting with the other components. It's time to dive into the source and see what's really happening under the hood. |
| 10/2 | 2026/09/11 08:50 | tool | grepper |
0mArgs:{
"Expression": "(pagewalk|huge_memory|migrate|uprobes)\\.o",
"PathPrefix": "mm/Makefile"
}Results: {
"Output": "mm/Makefile=37=mmu-$(CONFIG_MMU)\t:= highmem.o memory.o mincore.o \\\nmm/Makefile-38-\t\t\t mlock.o mmap.o mmu_gather.o mprotect.o mremap.o \\\nmm/Makefile:39:\t\t\t msync.o page_vma_mapped.o pagewalk.o \\\nmm/Makefile-40-\t\t\t pgtable-generic.o rmap.o vmalloc.o vma.o vma_exec.o\n--\nmm/Makefile=98=obj-$(CONFIG_MEMTEST)\t\t+= memtest.o\nmm/Makefile:99:obj-$(CONFIG_MIGRATION) += migrate.o\nmm/Makefile-100-obj-$(CONFIG_NUMA) += memory-tiers.o\nmm/Makefile=101=obj-$(CONFIG_DEVICE_MIGRATION) += migrate_device.o\nmm/Makefile:102:obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o\nmm/Makefile-103-obj-$(CONFIG_PAGE_COUNTER) += page_counter.o\n"
} |
| 11/2 | 2026/09/11 08:50 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 11142 output: 30 thoughts: 17 Thoughts: Here's my take on those thoughts, tailored for an expert audience: **Kernel Uprobe Debugging - Makefile Deep Dive** Okay, so I'm diving into this uprobes thing. I need to figure out where the `uprobes.o` object file is being built within the kernel source. My first instinct is to check the `kernel/events/Makefile`. It's a pretty standard convention to find related object files defined in that directory's Makefile, especially given the `kernel/events` context. This is a common pattern for kernel component build structures and organization. Hopefully, it's a straightforward include or definition there, and I can quickly trace its dependencies and build process from there. Time to see what we've got! |
| 12/2 | 2026/09/11 08:50 | tool | grepper |
0mArgs:{
"Expression": "uprobes\\.o",
"PathPrefix": "kernel/events/Makefile"
}Results: {
"Output": "kernel/events/Makefile=5=obj-$(CONFIG_HW_BREAKPOINT_KUNIT_TEST) += hw_breakpoint_test.o\nkernel/events/Makefile:6:obj-$(CONFIG_UPROBES) += uprobes.o\n"
} |
| 13/2 | 2026/09/11 08:50 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 11413 output: 27 thoughts: 31 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: **Investigating Potential Locking Issues with PGWALK_VMA_RDLOCK_VERIFY** Right, let's dive into this. The first thing I need to do is confirm precisely what `PGWALK_VMA_RDLOCK_VERIFY` actually *does*. I need to refresh my memory on the specific definition of that macro – what are its intended checks, what are the conditions it's designed to flag? Is it related to read-only access in some way? Or is it a more general validation tool? Understanding the *purpose* is critical before I can assess any potential problem. Next, I have to consider the per-VMA (Virtual Memory Area) lock configurations. Are there any custom configurations that could be interfering with or unexpectedly interacting with the verification checks performed by this macro? Are there any unusual lock settings that are happening on those VMAs? Are the assumptions of the lock system being broken somehow? This is particularly important because `PGWALK` is related to page table walks, which are a critical area for concurrency and memory management. Any inconsistencies here can have severe ramifications. Let's see if this macro can help me, or if it might be a part of the problem. |
| 14/2 | 2026/09/11 08:51 | tool | grepper |
0mArgs:{
"Expression": "PGWALK_VMA_RDLOCK_VERIFY"
}Results: {
"Output": "fs/proc/task_mmu.c=1253=static const struct mm_walk_ops smaps_walk_vma_lock_ops = {\n--\nfs/proc/task_mmu.c-1255-\t.hugetlb_entry\t\t= smaps_hugetlb_range,\nfs/proc/task_mmu.c:1256:\t.walk_lock\t\t= PGWALK_VMA_RDLOCK_VERIFY,\nfs/proc/task_mmu.c-1257-};\n--\nfs/proc/task_mmu.c=1259=static const struct mm_walk_ops smaps_shmem_walk_vma_lock_ops = {\n--\nfs/proc/task_mmu.c-1262-\t.pte_hole\t\t= smaps_pte_hole,\nfs/proc/task_mmu.c:1263:\t.walk_lock\t\t= PGWALK_VMA_RDLOCK_VERIFY,\nfs/proc/task_mmu.c-1264-};\n--\nfs/proc/task_mmu.c=3418=static const struct mm_walk_ops show_numa_vma_lock_ops = {\n--\nfs/proc/task_mmu.c-3420-\t.pmd_entry = gather_pte_stats,\nfs/proc/task_mmu.c:3421:\t.walk_lock = PGWALK_VMA_RDLOCK_VERIFY,\nfs/proc/task_mmu.c-3422-};\n--\ninclude/linux/pagewalk.h=10=enum page_walk_lock {\n--\ninclude/linux/pagewalk.h-17-\t/* vma is expected to be already read-locked during the walk */\ninclude/linux/pagewalk.h:18:\tPGWALK_VMA_RDLOCK_VERIFY = 3,\ninclude/linux/pagewalk.h-19-};\n--\nmm/damon/vaddr.c=229=static void damon_va_walk_page_range(struct mm_struct *mm, unsigned long start,\n--\nmm/damon/vaddr.c-243-\tif (!(vma-\u003evm_flags \u0026 VM_PFNMAP)) {\nmm/damon/vaddr.c:244:\t\tops-\u003ewalk_lock = PGWALK_VMA_RDLOCK_VERIFY;\nmm/damon/vaddr.c-245-\t\twalk_page_range_vma(vma, start, end, ops, private);\n--\nmm/ksm.c=806=static void break_cow(struct ksm_rmap_item *rmap_item)\n--\nmm/ksm.c-826-\nmm/ksm.c:827:\tbreak_ksm(vma, addr, addr + PAGE_SIZE, PGWALK_VMA_RDLOCK_VERIFY);\nmm/ksm.c-828-\tvma_end_read(vma);\n--\nmm/ksm.c=831=static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)\n--\nmm/ksm.c-838-\tstruct folio_walk fw = {\nmm/ksm.c:839:\t\t.walk_lock = PGWALK_VMA_RDLOCK_VERIFY,\nmm/ksm.c-840-\t};\n--\nmm/madvise.c=798=static inline enum page_walk_lock get_walk_lock(enum madvise_lock_mode mode)\n--\nmm/madvise.c-801-\tcase MADVISE_VMA_READ_LOCK:\nmm/madvise.c:802:\t\treturn PGWALK_VMA_RDLOCK_VERIFY;\nmm/madvise.c-803-\tcase MADVISE_MMAP_READ_LOCK:\n--\nmm/pagewalk.c=435=static inline void process_mm_walk_lock(struct mm_struct *mm,\n--\nmm/pagewalk.c-439-\t\tmmap_assert_locked(mm);\nmm/pagewalk.c:440:\telse if (walk_lock != PGWALK_VMA_RDLOCK_VERIFY)\nmm/pagewalk.c-441-\t\tmmap_assert_write_locked(mm);\n--\nmm/pagewalk.c=444=static inline void process_vma_walk_lock(struct vm_area_struct *vma,\n--\nmm/pagewalk.c-453-\t\tbreak;\nmm/pagewalk.c:454:\tcase PGWALK_VMA_RDLOCK_VERIFY:\nmm/pagewalk.c-455-\t\tvma_assert_locked(vma);\n--\nmm/pagewalk.c=899=struct folio *folio_walk_start(struct folio_walk *fw,\n--\nmm/pagewalk.c-916-\t */\nmm/pagewalk.c:917:\tif (fw-\u003ewalk_lock != PGWALK_RDLOCK \u0026\u0026 fw-\u003ewalk_lock != PGWALK_VMA_RDLOCK_VERIFY)\nmm/pagewalk.c-918-\t\tWARN_ONCE(1, \"walk_lock is not expected!\\n\");\n"
} |
| 15/2 | 2026/09/11 08:51 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 13076 output: 29 thoughts: 25 Thoughts: Here's my thought process, as requested: **Investigating Per-VMA Locking Configuration** Okay, so I need to figure out what's controlling the per-VMA locking mechanism. My immediate thought is to check the `Kconfig` file. That's usually the go-to place for kernel configuration options, right? Specifically, I'm after `PER_VMA_LOCK`. That's the likely key. I need to understand exactly what that option does and how it's defined, as it will reveal the circumstances under which the kernel will employ per-VMA locking. This should tell me what I need to know about the feature. Let's dig in. |
| 16/2 | 2026/09/11 08:51 | tool | grepper |
0mArgs:{
"Expression": "config PER_VMA_LOCK",
"PathPrefix": "mm/"
}Results: {
"Output": "mm/Kconfig.debug=300=config DEBUG_KMEMLEAK_VERBOSE\n--\nmm/Kconfig.debug-310-\nmm/Kconfig.debug:311:config PER_VMA_LOCK_STATS\nmm/Kconfig.debug-312-\tbool \"Statistics for per-vma locks\"\n"
} |
| 17/2 | 2026/09/11 08:51 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 13367 output: 23 thoughts: 17 Thoughts: Here's my take on those thoughts: **Deep Dive Time: Checking `PER_VMA_LOCK` in the Kernel** Okay, so I'm thinking, "Right, let's get down to brass tacks and really understand the usage of `PER_VMA_LOCK` across the *entire* kernel." I need to get a comprehensive view of how this lock is being used. I know its purpose, but I need to see the implementation in context. I'm going to start with a systematic search and analysis. No surface-level skimming here; I need the granularity to really understand the implications of its application. I'm going to track its use across different architectures and subsystems. I need a clear mental picture of where it's critical, where it's potentially redundant, and anything that could lead to unexpected behavior. This is going to be thorough. Let's dig in. |
| 18/2 | 2026/09/11 08:51 | tool | grepper |
0mError:no matches Args: {
"Expression": "config PER_VMA_LOCK\\b"
}Results: {
"error": "no matches"
} |
| 19/2 | 2026/09/11 08:51 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 13611 output: 33 thoughts: 14 Thoughts: Here's a summary of my thought process: **Diving into `PER_VMA_LOCK`** Okay, so I need to understand this `PER_VMA_LOCK` definition better. Given my expertise, I'm going to quickly get up to speed with its nuances. I need to be sure I'm not missing anything critical in my understanding of its application. I'll need to go beyond a superficial glance. I'll need to know exactly what it means and how it's used. Let's start with a thorough check of the definition. |
| 20/2 | 2026/09/11 08:51 | tool | grepper |
0mError:no matches Args: {
"Expression": "PER_VMA_LOCK",
"PathPrefix": "include/linux/mm.h"
}Results: {
"error": "no matches"
} |
| 21/2 | 2026/09/11 08:51 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 13794 output: 23 thoughts: 19 Thoughts: Here's my thought process, as if I were thinking it: **Digging into `vma_start_read_unlocked`** Okay, so I need to understand what's happening with `vma_start_read_unlocked`. First things first, let's find its definition. Knowing where it's defined will give me the most fundamental information about its purpose, parameters, and likely, the data structures it operates on. This should point me to the core of its functionality within the virtual memory area (VMA) management code. From there, I can trace its call sites and see how it fits into the broader picture of memory management operations, likely involving locking/unlocking schemes and read/write access. This initial search is essential. I'm expecting this will be a function, but it could be a macro, so I need to check either way. Once I have the definition, I can start forming a mental model of its impact. |
| 22/2 | 2026/09/11 08:51 | tool | grepper |
0mArgs:{
"Expression": "vma_start_read_unlocked"
}Results: {
"Output": "drivers/android/binder/page_range.rs=401= unsafe fn use_page_slow(\u0026self, i: usize) -\u003e Result\u003c()\u003e {\n--\ndrivers/android/binder/page_range.rs-441- {\ndrivers/android/binder/page_range.rs:442: let vma_read_guard = mm.vma_start_read_unlocked(vma_addr).ok_or(ESRCH)?;\ndrivers/android/binder/page_range.rs-443- let vma = check_vma(\u0026vma_read_guard, self).ok_or(ESRCH)?;\n--\ndrivers/android/binder_alloc.c=254=static int binder_page_insert(struct binder_alloc *alloc,\n--\ndrivers/android/binder_alloc.c-261-\ndrivers/android/binder_alloc.c:262:\tvma = vma_start_read_unlocked(mm, addr);\ndrivers/android/binder_alloc.c-263-\tif (!vma)\n--\ninclude/linux/mmap_lock.h=263=static inline bool vma_start_read_locked(struct vm_area_struct *vma)\n--\ninclude/linux/mmap_lock.h-267-\ninclude/linux/mmap_lock.h:268:struct vm_area_struct *vma_start_read_unlocked(struct mm_struct *mm,\ninclude/linux/mmap_lock.h-269-\t\t\t\t\t unsigned long address);\n--\nmm/ksm.c=781=static struct vm_area_struct *find_mergeable_vma_locked(struct mm_struct *mm,\n--\nmm/ksm.c-788-\nmm/ksm.c:789:\tvma = vma_start_read_unlocked(mm, address);\nmm/ksm.c-790-\tif (!vma)\n--\nmm/mmap_lock.c=293=struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm,\n--\nmm/mmap_lock.c-343-/**\nmm/mmap_lock.c:344: * vma_start_read_unlocked() - Find the VMA covering 'address' and read-lock it.\nmm/mmap_lock.c-345- * @mm: the mm_struct of the address space to search\n--\nmm/mmap_lock.c-357- */\nmm/mmap_lock.c:358:struct vm_area_struct *vma_start_read_unlocked(struct mm_struct *mm,\nmm/mmap_lock.c-359-\t\t\t\t\t unsigned long address)\n--\nnet/ipv4/tcp.c=2170=static struct vm_area_struct *find_tcp_vma(struct mm_struct *mm,\n--\nnet/ipv4/tcp.c-2172-{\nnet/ipv4/tcp.c:2173:\tstruct vm_area_struct *vma = vma_start_read_unlocked(mm, address);\nnet/ipv4/tcp.c-2174-\n--\nrust/kernel/mm.rs=174= pub fn lock_vma_under_rcu(\u0026self, vma_addr: usize) -\u003e Option\u003cVmaReadGuard\u003c'_\u003e\u003e {\n--\nrust/kernel/mm.rs-200- #[inline]\nrust/kernel/mm.rs:201: pub fn vma_start_read_unlocked(\u0026self, vma_addr: usize) -\u003e Option\u003cVmaReadGuard\u003c'_\u003e\u003e {\nrust/kernel/mm.rs:202: // SAFETY: We may invoke `vma_start_read_unlocked` because we know this `mm` has non-zero\nrust/kernel/mm.rs-203- // `mm_users`.\nrust/kernel/mm.rs:204: let vma = unsafe { bindings::vma_start_read_unlocked(self.as_raw(), vma_addr) };\nrust/kernel/mm.rs-205- if vma.is_null() {\n--\nrust/kernel/mm.rs-209- Some(VmaReadGuard {\nrust/kernel/mm.rs:210: // SAFETY: If `vma_start_read_unlocked` returns a non-null ptr, then it points at a\nrust/kernel/mm.rs-211- // valid vma. The vma is stable for as long as the vma read lock is held.\n"
} |
| 23/2 | 2026/09/11 08:51 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 15179 output: 256 thoughts: 1711 Thoughts: **Fuzzing Plan for Memory Management Patch** Okay, so I'm diving into this patch series. My initial thought is to identify the critical areas for fuzzing to uncover potential issues, given the likely impact on core memory management. First, I need to confirm the relevant configuration options. `CONFIG_KSM` is the main one for Kernel Samepage Merging, and I'll also check for `CONFIG_TRANSPARENT_HUGEPAGE`, `CONFIG_MIGRATION`, and `CONFIG_UPROBES` as they seem related to the modified components. Next, I need to list the impacted functions to get an idea of the scope. I see several functions within `mm/ksm.c` like `find_mergeable_vma_locked`, `break_ksm`, `break_cow`, `get_mergeable_page`, `try_to_merge_with_zero_page`, `try_to_merge_with_ksm_page`, and `ksm_madvise`. There are also modifications to `folio_walk_start` in `mm/pagewalk.c`, `split_huge_pages_pid` in `mm/huge_memory.c`, `add_folio_for_migration` and `do_pages_stat_array` in `mm/migrate.c`, `make_device_exclusive` in `mm/rmap.c`, and finally `uprobe_write` in `kernel/events/uprobes.c`. Now, I'll identify the functions that are the best targets for fuzzing. I'll need to prioritize functions that are specific to the feature logic or entrypoints and avoid the ubiquitous lifecycle hot-paths. `folio_walk_start` is interesting as it's a pagewalk helper with new assertions and locking checks. `break_ksm` is another one, given the locking changes. The KSM helpers (`break_cow`, `get_mergeable_page`, `try_to_merge_with_zero_page`, `try_to_merge_with_ksm_page`, `find_mergeable_vma_locked`), `ksm_madvise`, `split_huge_pages_pid`, are all likely candidates. Finally, I'll include these others: `add_folio_for_migration`, `do_pages_stat_array`, `make_device_exclusive`, and `uprobe_write`. Let's check whether static or non-static functions are preferable here. It seems that most static functions will be resolved but it may be worth checking if well-known entrypoints are better targets. The important functions seem to be well-known entrypoints. `ksm_madvise` is called from `madvise_vma_behavior`. `folio_walk_start` is exported/callable across `mm`. `break_ksm` is called in `ksm.c`. `split_huge_pages_pid` is in `mm/huge_memory.c`. Then, I'll double-check those config options: `KSM`, `TRANSPARENT_HUGEPAGE`, `MIGRATION`, and `UPROBES`. Finally, the `set-results` parameters: * `WorthFuzzing`: True. * `Reasoning`: This is a significant patch series because it touches core memory management code, changing page table walking, and KSM locking semantics across pagewalk, KSM, THP, migration, rmap, and uprobes. It introduces locking semantics changes and defensive assertions. * `FocusSymbols`: `["folio_walk_start", "break_ksm", "find_mergeable_vma_locked", "get_mergeable_page", "try_to_merge_with_ksm_page", "try_to_merge_with_zero_page", "ksm_madvise", "break_cow", "split_huge_pages_pid"]`. * `EnableConfigs`: `["KSM", "TRANSPARENT_HUGEPAGE", "MIGRATION", "UPROBES"]`. I'll sanity check the approach against the stated goals for patch fuzzing: reachability, focusing on new/modified assertions, and avoiding the overly generic. This seems good. Time to execute this plan. |
| 24/2 | 2026/09/11 08:51 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"KSM",
"TRANSPARENT_HUGEPAGE",
"MIGRATION",
"UPROBES"
],
"FocusSymbols": [
"folio_walk_start",
"break_ksm",
"find_mergeable_vma_locked",
"get_mergeable_page",
"try_to_merge_with_ksm_page",
"try_to_merge_with_zero_page",
"ksm_madvise",
"break_cow",
"split_huge_pages_pid"
],
"Reasoning": "The patch modifies page walking and KSM locking semantics across core memory management (pagewalk, KSM, THP, migration, rmap, uprobes). It introduces per-VMA read locking (PGWALK_VMA_RDLOCK_VERIFY via vma_start_read_unlocked) to KSM routines, dynamically alters break_ksm_ops walk locking, and adds locking validation checks/assertions in folio_walk_start. These changes alter locking invariants and state management in reachable core mm code.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"KSM",
"TRANSPARENT_HUGEPAGE",
"MIGRATION",
"UPROBES"
],
"FocusSymbols": [
"folio_walk_start",
"break_ksm",
"find_mergeable_vma_locked",
"get_mergeable_page",
"try_to_merge_with_ksm_page",
"try_to_merge_with_zero_page",
"ksm_madvise",
"break_cow",
"split_huge_pages_pid"
],
"Reasoning": "The patch modifies page walking and KSM locking semantics across core memory management (pagewalk, KSM, THP, migration, rmap, uprobes). It introduces per-VMA read locking (PGWALK_VMA_RDLOCK_VERIFY via vma_start_read_unlocked) to KSM routines, dynamically alters break_ksm_ops walk locking, and adds locking validation checks/assertions in folio_walk_start. These changes alter locking invariants and state management in reachable core mm code.",
"WorthFuzzing": true
} |
| 25/1 | 2026/09/11 08:51 | action | If |
0mArgs:{
"WorthFuzzing": true
}Results: null |
| 26/2 | 2026/09/11 08:51 | agent | kmsan-evaluator |
0mModel:core Args: null Results: {
"KMSANReasoning": "The patch refactors page walk locking and transitions KSM from mmap_read_lock to per-VMA read locking (vma_start_read_unlocked/vma_end_read) with lock verification in folio_walk_start(). All local instances of `struct folio_walk` across the codebase are explicitly initialized with designated initializers (`struct folio_walk fw = { .walk_lock = ... };`), which zero-initializes the remaining fields as per C semantics. No kernel buffers or structures are copied to userspace, no uninitialized memory is read or branched upon, and the patch primarily alters locking/synchronization semantics (which are monitored by LOCKDEP and KASAN). Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
}Instruction: You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.
CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
a comprehensive suite of debugging tools and sanitizers, including KASAN
(out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
(locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
or page allocations) and kernel-to-user memory info-leaks.
Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.
Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.
Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
attributes, ioctl output arguments, socket options, or BPF buffers) where fields
or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
uninitialized bytes of existing buffers.
Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
dereferences, locking deadlocks, or use-after-free bugs (these are already caught
by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.
Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit ac265eb0d7b755f668cc5b0ecc34f057a6ca756f
Author: syz-cluster <triage@syzkaller.com>
Date: Fri Sep 11 08:50:22 2026 +0000
syz-cluster: applied patch under review
diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
index 46d828926009b..968f128a52320 100644
--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -412,7 +412,9 @@ __context_unsafe(/* folio_walk_end() not instrumented */)
unsigned long addr = get_fault_address(regs);
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
int rc;
diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
index b41d7265c01bc..455428eaf1fc0 100644
--- a/include/linux/pagewalk.h
+++ b/include/linux/pagewalk.h
@@ -183,8 +183,8 @@ struct folio_walk {
pmd_t pmd;
};
/* private */
- struct vm_area_struct *vma;
spinlock_t *ptl;
+ enum page_walk_lock walk_lock;
};
struct folio *folio_walk_start(struct folio_walk *fw,
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 7709ea8824778..054fdcb521366 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -507,7 +507,9 @@ int uprobe_write(struct arch_uprobe *auprobe, struct vm_area_struct *vma,
int ret, ref_ctr_updated = 0;
unsigned int gup_flags = FOLL_FORCE;
struct mmu_notifier_range range;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
struct page *page;
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 30b7c63b0e359..d0447b6ae6e41 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -4810,7 +4810,9 @@ static int split_huge_pages_pid(int pid, unsigned long vaddr_start,
*/
for (addr = vaddr_start; addr < vaddr_end; addr += PAGE_SIZE) {
struct vm_area_struct *vma = vma_lookup(mm, addr);
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
struct address_space *mapping;
unsigned int target_order = new_order;
diff --git a/mm/ksm.c b/mm/ksm.c
index 624f37975e129..1d85769ec7dbe 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -660,16 +660,11 @@ static int break_ksm_pmd_entry(pmd_t *pmdp, unsigned long addr, unsigned long en
return found;
}
-static const struct mm_walk_ops break_ksm_ops = {
+static struct mm_walk_ops break_ksm_ops = {
.pmd_entry = break_ksm_pmd_entry,
.walk_lock = PGWALK_RDLOCK,
};
-static const struct mm_walk_ops break_ksm_lock_vma_ops = {
- .pmd_entry = break_ksm_pmd_entry,
- .walk_lock = PGWALK_WRLOCK,
-};
-
/*
* Though it's very tempting to unmerge rmap_items from stable tree rather
* than check every pte of a given vma, the locking doesn't quite work for
@@ -696,11 +691,11 @@ static const struct mm_walk_ops break_ksm_lock_vma_ops = {
* protection keys here anyway.
*/
static int break_ksm(struct vm_area_struct *vma, unsigned long addr,
- unsigned long end, bool lock_vma)
+ unsigned long end, enum page_walk_lock walk_lock)
{
vm_fault_t ret = 0;
- const struct mm_walk_ops *ops = lock_vma ?
- &break_ksm_lock_vma_ops : &break_ksm_ops;
+ struct mm_walk_ops *ops = &break_ksm_ops;
+ ops->walk_lock = walk_lock;
do {
int ksm_page;
@@ -770,15 +765,36 @@ static bool vma_ksm_compatible(struct vm_area_struct *vma)
return ksm_compatible(vma->vm_file, vma->flags);
}
-static struct vm_area_struct *find_mergeable_vma(struct mm_struct *mm,
- unsigned long addr)
+/**
+ * find_mergeable_vma_locked() - Find the VMA covering 'address' which is
+ * VM_MERGEABLE and read-lock it by per-VMA locks. Please use vma_end_read()
+ * to unlock vma after finishing reading the VMA (non-NULL).
+ *
+ * Return: If a VMA exists which spans @address, return that VMA, read-locked.
+ * If no VMA is mapped there or, very unlikely, a reference count overflow
+ * occurred, return NULL, and no read-locked.
+ *
+ * IMPORTANT: If a VMA exists but is not VM_MERGEABLE or has no anon_vma,
+ * this function releases the per-VMA read lock before returning NULL.
+ * Callers must NOT call vma_end_read() on a NULL return value.
+ */
+static struct vm_area_struct *find_mergeable_vma_locked(struct mm_struct *mm,
+ unsigned long address)
{
struct vm_area_struct *vma;
+
if (ksm_test_exit(mm))
return NULL;
- vma = vma_lookup(mm, addr);
- if (!vma || !(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
+
+ vma = vma_start_read_unlocked(mm, address);
+ if (!vma)
+ return NULL;
+
+ if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma) {
+ vma_end_read(vma);
return NULL;
+ }
+
return vma;
}
@@ -804,11 +820,12 @@ static void break_cow(struct ksm_rmap_item *rmap_item)
*/
rmap_item->linear_page_index = 0;
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, addr);
- if (vma)
- break_ksm(vma, addr, addr + PAGE_SIZE, false);
- mmap_read_unlock(mm);
+ vma = find_mergeable_vma_locked(mm, addr);
+ if (!vma)
+ return;
+
+ break_ksm(vma, addr, addr + PAGE_SIZE, PGWALK_VMA_RDLOCK_VERIFY);
+ vma_end_read(vma);
}
static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)
@@ -817,13 +834,14 @@ static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)
unsigned long addr = rmap_item->address;
struct vm_area_struct *vma;
struct page *page = NULL;
- struct folio_walk fw;
struct folio *folio;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_VMA_RDLOCK_VERIFY,
+ };
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, addr);
+ vma = find_mergeable_vma_locked(mm, addr);
if (!vma)
- goto out;
+ return NULL;
folio = folio_walk_start(&fw, vma, addr, 0);
if (folio) {
@@ -834,12 +852,12 @@ static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)
}
folio_walk_end(&fw, vma);
}
-out:
+
if (page) {
flush_anon_page(vma, page, addr);
flush_dcache_page(page);
}
- mmap_read_unlock(mm);
+ vma_end_read(vma);
return page;
}
@@ -1243,7 +1261,7 @@ static int unmerge_and_remove_all_rmap_items(void)
for_each_vma(vmi, vma) {
if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
continue;
- err = break_ksm(vma, vma->vm_start, vma->vm_end, false);
+ err = break_ksm(vma, vma->vm_start, vma->vm_end, PGWALK_RDLOCK);
if (err)
goto error;
}
@@ -1571,14 +1589,14 @@ static int try_to_merge_with_zero_page(struct ksm_rmap_item *rmap_item,
if (ksm_use_zero_pages && (rmap_item->oldchecksum == zero_checksum)) {
struct vm_area_struct *vma;
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, rmap_item->address);
+ vma = find_mergeable_vma_locked(mm, rmap_item->address);
if (vma) {
err = try_to_merge_one_page(vma, page,
ZERO_PAGE(rmap_item->address));
trace_ksm_merge_one_page(
page_to_pfn(ZERO_PAGE(rmap_item->address)),
rmap_item, mm, err);
+ vma_end_read(vma);
} else {
/*
* If the vma is out of date, we do not need to
@@ -1586,7 +1604,6 @@ static int try_to_merge_with_zero_page(struct ksm_rmap_item *rmap_item,
*/
err = 0;
}
- mmap_read_unlock(mm);
}
return err;
@@ -1605,10 +1622,9 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,
struct vm_area_struct *vma;
int err = -EFAULT;
- mmap_read_lock(mm);
- vma = find_mergeable_vma(mm, rmap_item->address);
+ vma = find_mergeable_vma_locked(mm, rmap_item->address);
if (!vma)
- goto out;
+ goto out_trace;
err = try_to_merge_one_page(vma, page, kpage);
if (err)
@@ -1628,7 +1644,8 @@ static int try_to_merge_with_ksm_page(struct ksm_rmap_item *rmap_item,
rmap_item->linear_page_index = linear_anon_page_index(vma, rmap_item->address);
get_anon_vma(vma->anon_vma);
out:
- mmap_read_unlock(mm);
+ vma_end_read(vma);
+out_trace:
trace_ksm_merge_with_ksm_page(kpage, page_to_pfn(kpage ? kpage : page),
rmap_item, mm, err);
return err;
@@ -2883,7 +2900,7 @@ static int __ksm_del_vma(struct vm_area_struct *vma)
return 0;
if (vma->anon_vma) {
- err = break_ksm(vma, vma->vm_start, vma->vm_end, true);
+ err = break_ksm(vma, vma->vm_start, vma->vm_end, PGWALK_WRLOCK);
if (err)
return err;
}
@@ -3035,7 +3052,7 @@ int ksm_madvise(struct vm_area_struct *vma, unsigned long start,
return 0; /* just ignore the advice */
if (vma->anon_vma) {
- err = break_ksm(vma, start, end, true);
+ err = break_ksm(vma, start, end, PGWALK_WRLOCK);
if (err)
return err;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index a369d0c95c386..2e078c1e1b9a6 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2302,7 +2302,9 @@ static int add_folio_for_migration(struct mm_struct *mm, const void __user *p,
int node, struct list_head *pagelist, bool migrate_all)
{
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
unsigned long addr;
int err = -EFAULT;
@@ -2464,7 +2466,9 @@ static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages,
for (i = 0; i < nr_pages; i++) {
unsigned long addr = (unsigned long)(*pages);
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct folio *folio;
int err = -EFAULT;
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index 7411702a37f58..8eb29fba20ad9 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -910,7 +910,15 @@ struct folio *folio_walk_start(struct folio_walk *fw,
pgd_t *pgdp;
p4d_t *p4dp;
- mmap_assert_locked(vma->vm_mm);
+ /*
+ * Other locking modes except for mmap or vma read locking are not
+ * expected.
+ */
+ if (fw->walk_lock != PGWALK_RDLOCK && fw->walk_lock != PGWALK_VMA_RDLOCK_VERIFY)
+ WARN_ONCE(1, "walk_lock is not expected!\n");
+ process_mm_walk_lock(vma->vm_mm, fw->walk_lock);
+ process_vma_walk_lock(vma, fw->walk_lock);
+
vma_pgtable_walk_begin(vma);
if (WARN_ON_ONCE(addr < vma->vm_start || addr >= vma->vm_end))
diff --git a/mm/rmap.c b/mm/rmap.c
index 5332c52909be1..0ca24bcf95703 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -2871,7 +2871,9 @@ struct page *make_device_exclusive(struct mm_struct *mm, unsigned long addr,
struct mmu_notifier_range range;
struct folio *folio, *fw_folio;
struct vm_area_struct *vma;
- struct folio_walk fw;
+ struct folio_walk fw = {
+ .walk_lock = PGWALK_RDLOCK,
+ };
struct page *page;
swp_entry_t entry;
pte_t swp_pte;
|
| 27/3 | 2026/09/11 08:51 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 6461 output: 19 thoughts: 534 Thoughts: **Analyzing the Memory Safety Impact of This Patch** Okay, let's dive into this patch and assess its potential impact on memory safety, specifically focusing on uninitialized memory risks that KMSAN might expose. I need to determine if this patch necessitates KMSAN or if standard KASAN, LOCKDEP, and related tools are sufficient. First, I'm seeing changes to the memory management code, particularly around page walking, dealing with things like `folio_walk`, `mm_walk_ops`, and KSM. This is interesting, and likely important. Looking at the diff, I note the following changes: 1. In `include/linux/pagewalk.h`, the `struct folio_walk` has had `struct vm_area_struct *vma;` removed and now includes `enum page_walk_lock walk_lock;`. That's a structural change, and the implication is that the lock type is now explicitly managed as part of the walk. 2. I see multiple call sites (within `arch/s390/mm/fault.c`, `kernel/events/uprobes.c`, `mm/huge_memory.c`, `mm/migrate.c`, and `mm/rmap.c`) where `struct folio_walk fw` is now explicitly initialized with `.walk_lock = PGWALK_RDLOCK` rather than simply being declared. This suggests they are explicitly defining the lock type at initialization time, which is a key observation. 3. The changes in `mm/ksm.c` are particularly noteworthy. I see modifications to `break_ksm_ops` (which is now not `const`) and `break_ksm` (now taking `enum page_walk_lock walk_lock`). The introduction of `find_mergeable_vma_locked` suggests a shift towards per-VMA locks (using `vma_start_read_unlocked` and `vma_end_read`) instead of the broader `mmap_read_lock(mm)` for KSM operations. `PGWALK_VMA_RDLOCK_VERIFY` is now utilized in the walk. This looks like a refinement of locking granularity and potentially improved concurrency. In `get_mergeable_page`, `struct folio_walk fw` is initialized with `.walk_lock = PGWALK_VMA_RDLOCK_VERIFY`. 4. In `mm/pagewalk.c`, `folio_walk_start` now checks `fw->walk_lock` and calls `process_mm_walk_lock` and `process_vma_walk_lock` which is very important. My key concern is whether there are any other places in the kernel where `struct folio_walk` is used and where `fw` might still be left uninitialized, or where there's a potential risk of reading uninitialized memory, leading to information leaks or other memory safety issues. I'll need to use my grepper tool to search the codebase for `struct folio_walk` and `folio_walk_start` to get a complete picture and identify any other call sites. I need to make sure that this initialization pattern is consistently applied throughout the relevant parts of the kernel. This is essential for a thorough assessment. |
| 28/3 | 2026/09/11 08:51 | tool | grepper |
0mArgs:{
"Expression": "folio_walk_start"
}Results: {
"Output": "arch/s390/mm/fault.c=409=__context_unsafe(/* folio_walk_end() not instrumented */)\n--\narch/s390/mm/fault.c-457-\t\t\treturn handle_fault_error_nolock(regs, SEGV_MAPERR);\narch/s390/mm/fault.c:458:\t\tfolio = folio_walk_start(\u0026fw, vma, addr, 0);\narch/s390/mm/fault.c-459-\t\tif (!folio)\n--\ninclude/linux/pagewalk.h=154=enum folio_walk_level {\n--\ninclude/linux/pagewalk.h-160-/**\ninclude/linux/pagewalk.h:161: * struct folio_walk - folio_walk_start() / folio_walk_end() data\ninclude/linux/pagewalk.h-162- * @page:\texact folio page referenced (if applicable)\n--\ninclude/linux/pagewalk.h-168- *\ninclude/linux/pagewalk.h:169: * (see folio_walk_start() documentation for more details)\ninclude/linux/pagewalk.h-170- */\ninclude/linux/pagewalk.h=171=struct folio_walk {\n--\ninclude/linux/pagewalk.h-189-\ninclude/linux/pagewalk.h:190:struct folio *folio_walk_start(struct folio_walk *fw,\ninclude/linux/pagewalk.h-191-\t\tstruct vm_area_struct *vma, unsigned long addr,\n--\nkernel/events/uprobes.c=499=int uprobe_write(struct arch_uprobe *auprobe, struct vm_area_struct *vma,\n--\nkernel/events/uprobes.c-574-\t/* Walk the page tables again, to perform the actual update. */\nkernel/events/uprobes.c:575:\tif (folio_walk_start(\u0026fw, vma, vaddr, 0)) {\nkernel/events/uprobes.c-576-\t\tif (fw.page == page)\n--\nmm/huge_memory.c=4775=static int split_huge_pages_pid(int pid, unsigned long vaddr_start,\n--\nmm/huge_memory.c-4828-\nmm/huge_memory.c:4829:\t\tfolio = folio_walk_start(\u0026fw, vma, addr, 0);\nmm/huge_memory.c-4830-\t\tif (!folio)\n--\nmm/ksm.c=831=static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)\n--\nmm/ksm.c-845-\nmm/ksm.c:846:\tfolio = folio_walk_start(\u0026fw, vma, addr, 0);\nmm/ksm.c-847-\tif (folio) {\n--\nmm/migrate.c=2301=static int add_folio_for_migration(struct mm_struct *mm, const void __user *p,\n--\nmm/migrate.c-2316-\tif (vma \u0026\u0026 vma_migratable(vma)) {\nmm/migrate.c:2317:\t\tfolio = folio_walk_start(\u0026fw, vma, addr, FW_ZEROPAGE);\nmm/migrate.c-2318-\t\tif (folio) {\n--\nmm/migrate.c=2459=static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages,\n--\nmm/migrate.c-2478-\nmm/migrate.c:2479:\t\tfolio = folio_walk_start(\u0026fw, vma, addr, FW_ZEROPAGE);\nmm/migrate.c-2480-\t\tif (folio) {\n--\nmm/pagewalk.c=798=int walk_page_mapping(struct address_space *mapping, pgoff_t first_index,\n--\nmm/pagewalk.c-848-/**\nmm/pagewalk.c:849: * folio_walk_start - walk the page tables to a folio\nmm/pagewalk.c-850- * @fw: filled with information on success.\n--\nmm/pagewalk.c-898- */\nmm/pagewalk.c:899:struct folio *folio_walk_start(struct folio_walk *fw,\nmm/pagewalk.c-900-\t\tstruct vm_area_struct *vma, unsigned long addr,\n--\nmm/rmap.c=2868=struct page *make_device_exclusive(struct mm_struct *mm, unsigned long addr,\n--\nmm/rmap.c-2927-\t */\nmm/rmap.c:2928:\tfw_folio = folio_walk_start(\u0026fw, vma, addr, 0);\nmm/rmap.c-2929-\tif (fw_folio != folio || fw.page != page ||\n"
} |
| 29/3 | 2026/09/11 08:51 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 8953 output: 18 thoughts: 20 Thoughts: Here's my summary, as though I'm thinking it: **Digging into `struct folio_walk` Declarations** Alright, before I dive too deep into this specific instance of `struct folio_walk`, I should probably do a quick sanity check. I need to be sure I'm not missing something fundamental about its use elsewhere in the kernel. So, let's see... a quick grep through the source tree is in order. Let me scan for any other declarations of `struct folio_walk`. Knowing *all* the places this struct is defined could give me a broader understanding of its purpose, and potentially uncover some subtle interactions or undocumented assumptions that might be relevant here. Let's make sure I'm not missing any important context. |
| 30/3 | 2026/09/11 08:51 | tool | grepper |
0mArgs:{
"Expression": "struct folio_walk"
}Results: {
"Output": "arch/s390/mm/fault.c=409=__context_unsafe(/* folio_walk_end() not instrumented */)\n--\narch/s390/mm/fault.c-414-\tstruct vm_area_struct *vma;\narch/s390/mm/fault.c:415:\tstruct folio_walk fw = {\narch/s390/mm/fault.c-416-\t\t.walk_lock = PGWALK_RDLOCK,\n--\ninclude/linux/pagewalk.h=154=enum folio_walk_level {\n--\ninclude/linux/pagewalk.h-160-/**\ninclude/linux/pagewalk.h:161: * struct folio_walk - folio_walk_start() / folio_walk_end() data\ninclude/linux/pagewalk.h-162- * @page:\texact folio page referenced (if applicable)\n--\ninclude/linux/pagewalk.h-170- */\ninclude/linux/pagewalk.h:171:struct folio_walk {\ninclude/linux/pagewalk.h-172-\t/* public */\n--\ninclude/linux/pagewalk.h-189-\ninclude/linux/pagewalk.h:190:struct folio *folio_walk_start(struct folio_walk *fw,\ninclude/linux/pagewalk.h-191-\t\tstruct vm_area_struct *vma, unsigned long addr,\n--\nkernel/events/uprobes.c=405=static int __uprobe_write(struct vm_area_struct *vma,\nkernel/events/uprobes.c:406:\t\tstruct folio_walk *fw, struct folio *folio,\nkernel/events/uprobes.c-407-\t\tunsigned long insn_vaddr, uprobe_opcode_t *insn, int nbytes,\n--\nkernel/events/uprobes.c=499=int uprobe_write(struct arch_uprobe *auprobe, struct vm_area_struct *vma,\n--\nkernel/events/uprobes.c-509-\tstruct mmu_notifier_range range;\nkernel/events/uprobes.c:510:\tstruct folio_walk fw = {\nkernel/events/uprobes.c-511-\t\t.walk_lock = PGWALK_RDLOCK,\n--\nmm/huge_memory.c=4775=static int split_huge_pages_pid(int pid, unsigned long vaddr_start,\n--\nmm/huge_memory.c-4812-\t\tstruct vm_area_struct *vma = vma_lookup(mm, addr);\nmm/huge_memory.c:4813:\t\tstruct folio_walk fw = {\nmm/huge_memory.c-4814-\t\t\t.walk_lock = PGWALK_RDLOCK,\n--\nmm/ksm.c=831=static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)\n--\nmm/ksm.c-837-\tstruct folio *folio;\nmm/ksm.c:838:\tstruct folio_walk fw = {\nmm/ksm.c-839-\t\t.walk_lock = PGWALK_VMA_RDLOCK_VERIFY,\n--\nmm/migrate.c=2301=static int add_folio_for_migration(struct mm_struct *mm, const void __user *p,\n--\nmm/migrate.c-2304-\tstruct vm_area_struct *vma;\nmm/migrate.c:2305:\tstruct folio_walk fw = {\nmm/migrate.c-2306-\t\t.walk_lock = PGWALK_RDLOCK,\n--\nmm/migrate.c=2459=static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages,\n--\nmm/migrate.c-2468-\t\tstruct vm_area_struct *vma;\nmm/migrate.c:2469:\t\tstruct folio_walk fw = {\nmm/migrate.c-2470-\t\t\t.walk_lock = PGWALK_RDLOCK,\n--\nmm/pagewalk.c=798=int walk_page_mapping(struct address_space *mapping, pgoff_t first_index,\n--\nmm/pagewalk.c-898- */\nmm/pagewalk.c:899:struct folio *folio_walk_start(struct folio_walk *fw,\nmm/pagewalk.c-900-\t\tstruct vm_area_struct *vma, unsigned long addr,\n--\nmm/rmap.c=2868=struct page *make_device_exclusive(struct mm_struct *mm, unsigned long addr,\n--\nmm/rmap.c-2873-\tstruct vm_area_struct *vma;\nmm/rmap.c:2874:\tstruct folio_walk fw = {\nmm/rmap.c-2875-\t\t.walk_lock = PGWALK_RDLOCK,\n"
} |
| 31/3 | 2026/09/11 08:51 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 10403 output: 34 thoughts: 52 Thoughts: Okay, let's dive into these recent changes. **Diving Deep into `mm/ksm.c` and `mm/pagewalk.c`** Alright, I'm going to take a look at the rest of the modifications across `mm/ksm.c` and `mm/pagewalk.c` – gotta get a solid grasp of the big picture. Let's see what they've been up to here. I'll start by focusing on `mm/pagewalk.c`, and specifically, I need to understand how `folio_walk_start` and `folio_walk_end` are implemented. Those are key primitives in any page-walking implementation, and a thorough understanding of their interaction is essential. Time to dig in. |
| 32/3 | 2026/09/11 08:51 | tool | read-file |
0mArgs:{
"File": "mm/pagewalk.c",
"FirstLine": 900,
"LineCount": 80
}Results: {
"Contents": " 900:\t\t\tstruct vm_area_struct *vma, unsigned long addr,\n 901:\t\t\tfolio_walk_flags_t flags)\n 902:\t{\n 903:\t\tunsigned long entry_size;\n 904:\t\tbool zeropage = false;\n 905:\t\tstruct page *page;\n 906:\t\tpud_t *pudp, pud;\n 907:\t\tpmd_t *pmdp, pmd;\n 908:\t\tpte_t *ptep, pte;\n 909:\t\tspinlock_t *ptl;\n 910:\t\tpgd_t *pgdp;\n 911:\t\tp4d_t *p4dp;\n 912:\t\n 913:\t\t/*\n 914:\t\t * Other locking modes except for mmap or vma read locking are not\n 915:\t\t * expected.\n 916:\t\t */\n 917:\t\tif (fw-\u003ewalk_lock != PGWALK_RDLOCK \u0026\u0026 fw-\u003ewalk_lock != PGWALK_VMA_RDLOCK_VERIFY)\n 918:\t\t\tWARN_ONCE(1, \"walk_lock is not expected!\\n\");\n 919:\t\tprocess_mm_walk_lock(vma-\u003evm_mm, fw-\u003ewalk_lock);\n 920:\t\tprocess_vma_walk_lock(vma, fw-\u003ewalk_lock);\n 921:\t\n 922:\t\tvma_pgtable_walk_begin(vma);\n 923:\t\n 924:\t\tif (WARN_ON_ONCE(addr \u003c vma-\u003evm_start || addr \u003e= vma-\u003evm_end))\n 925:\t\t\tgoto not_found;\n 926:\t\n 927:\t\tpgdp = pgd_offset(vma-\u003evm_mm, addr);\n 928:\t\tif (pgd_none_or_clear_bad(pgdp))\n 929:\t\t\tgoto not_found;\n 930:\t\n 931:\t\tp4dp = p4d_offset(pgdp, addr);\n 932:\t\tif (p4d_none_or_clear_bad(p4dp))\n 933:\t\t\tgoto not_found;\n 934:\t\n 935:\t\tpudp = pud_offset(p4dp, addr);\n 936:\t\tpud = pudp_get(pudp);\n 937:\t\tif (pud_none(pud))\n 938:\t\t\tgoto not_found;\n 939:\t\tif (IS_ENABLED(CONFIG_PGTABLE_HAS_HUGE_LEAVES) \u0026\u0026\n 940:\t\t (!pud_present(pud) || pud_leaf(pud))) {\n 941:\t\t\tptl = pud_lock(vma-\u003evm_mm, pudp);\n 942:\t\t\tpud = pudp_get(pudp);\n 943:\t\n 944:\t\t\tentry_size = PUD_SIZE;\n 945:\t\t\tfw-\u003elevel = FW_LEVEL_PUD;\n 946:\t\t\tfw-\u003epudp = pudp;\n 947:\t\t\tfw-\u003epud = pud;\n 948:\t\n 949:\t\t\tif (pud_none(pud)) {\n 950:\t\t\t\tspin_unlock(ptl);\n 951:\t\t\t\tgoto not_found;\n 952:\t\t\t} else if (pud_present(pud) \u0026\u0026 !pud_leaf(pud)) {\n 953:\t\t\t\tspin_unlock(ptl);\n 954:\t\t\t\tgoto pmd_table;\n 955:\t\t\t} else if (pud_present(pud)) {\n 956:\t\t\t\tpage = vm_normal_page_pud(vma, addr, pud);\n 957:\t\t\t\tif (page)\n 958:\t\t\t\t\tgoto found;\n 959:\t\t\t}\n 960:\t\t\tspin_unlock(ptl);\n 961:\t\t\tgoto not_found;\n 962:\t\t}\n 963:\t\n 964:\tpmd_table:\n 965:\t\tVM_WARN_ON_ONCE(!pud_present(pud) || pud_leaf(pud));\n 966:\t\tpmdp = pmd_offset(pudp, addr);\n 967:\t\tpmd = pmdp_get_lockless(pmdp);\n 968:\t\tif (pmd_none(pmd))\n 969:\t\t\tgoto not_found;\n 970:\t\tif (IS_ENABLED(CONFIG_PGTABLE_HAS_HUGE_LEAVES) \u0026\u0026\n 971:\t\t (!pmd_present(pmd) || pmd_leaf(pmd))) {\n 972:\t\t\tptl = pmd_lock(vma-\u003evm_mm, pmdp);\n 973:\t\t\tpmd = pmdp_get(pmdp);\n 974:\t\n 975:\t\t\tentry_size = PMD_SIZE;\n 976:\t\t\tfw-\u003elevel = FW_LEVEL_PMD;\n 977:\t\t\tfw-\u003epmdp = pmdp;\n 978:\t\t\tfw-\u003epmd = pmd;\n 979:\t\n"
} |
| 33/3 | 2026/09/11 08:51 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 11984 output: 35 thoughts: 21 Thoughts: Here's my summary, as if I were thinking these thoughts: **Examining `folio_walk_end`** Alright, I'm diving back into this memory management stuff. Let's see... I've got a handle on the overall structure, but I need to zoom in on how these folio walks conclude. Specifically, I should check out `folio_walk_end` in `mm/pagewalk.c`. I need a clear understanding of what happens at the final stage of these walks, to make sure I'm not missing anything critical in how they work. Understanding its behavior and how it interacts with other functions is key. Let's see what's what. |
| 34/3 | 2026/09/11 08:51 | tool | read-file |
0mArgs:{
"File": "mm/pagewalk.c",
"FirstLine": 1020,
"LineCount": 40
}Results: {
"Contents": "1020:\t\t\t\tzeropage = true;\n1021:\t\t\t\tgoto found;\n1022:\t\t\t}\n1023:\t\t}\n1024:\t\tpte_unmap_unlock(ptep, ptl);\n1025:\tnot_found:\n1026:\t\tvma_pgtable_walk_end(vma);\n1027:\t\treturn NULL;\n1028:\tfound:\n1029:\t\tif (!zeropage)\n1030:\t\t\t/* Note: Offset from the mapped page, not the folio start. */\n1031:\t\t\tfw-\u003epage = page + ((addr \u0026 (entry_size - 1)) \u003e\u003e PAGE_SHIFT);\n1032:\t\telse\n1033:\t\t\tfw-\u003epage = NULL;\n1034:\t\tfw-\u003eptl = ptl;\n1035:\t\treturn page_folio(page);\n1036:\t}\n"
} |
| 35/3 | 2026/09/11 08:51 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 12429 output: 35 thoughts: 12 Thoughts: Okay, here's my attempt at summarizing the thought process, as if it were my own, assuming the user is an expert. **The End of the Walk: Reflections on `folio_walk_end`** Alright, so `folio_walk_end`. Time to break down what this means in the broader context of whatever I'm working on. It's the conclusion, the final checkpoint. I need to think about the implications. What's the state of the system *at* `folio_walk_end`? Have all the necessary resources been released? Are there any potential memory leaks, dangling pointers, or unclosed handles? Have I meticulously handled all the error conditions that could have cropped up during the walk itself? Specifically, what are the post-conditions, and how do they impact the system? Now I need to consider the external implications. How might subsequent functions or modules depend on this endpoint? Does it neatly package information for the next phase, or is there work to do? Did it trigger any notifications or logging, and are they sufficient for proper debugging? Was there some sort of cleanup process, and if so, did it occur correctly? Are there any critical edge cases I need to consider? Furthermore, I have to ensure the design is extensible. Am I setting myself up for future enhancements, or am I painting myself into a corner with this specific implementation? What would I need to change if the underlying data structure or process changes? Let me review the code one last time... ensure that the cleanup aligns with the original intent. No loose ends. |
| 36/3 | 2026/09/11 08:52 | tool | read-file |
0mError:file mm/pagewalk.c does not have line 1037, it has only 1036 lines Args: {
"File": "mm/pagewalk.c",
"FirstLine": 1037,
"LineCount": 40
}Results: {
"error": "file mm/pagewalk.c does not have line 1037, it has only 1036 lines"
} |
| 37/3 | 2026/09/11 08:52 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 12841 output: 19 thoughts: 15 Thoughts: Here's my take on those thoughts: **Tracing the Code's Footprints** Okay, so I'm trying to figure out how this `folio_walk_end` function is behaving. My first instinct is to pinpoint its definition. Where is it actually declared and implemented within this codebase? I need to understand its scope and, crucially, how it’s being used contextually. Locating the definition is the crucial first step. It's the starting point for understanding its role in the greater architecture, and how the program functions. I'm going to start with the obvious and work from there. Let’s see where the function is defined. |
| 38/3 | 2026/09/11 08:52 | tool | grepper |
0mArgs:{
"Expression": "folio_walk_end"
}Results: {
"Output": "arch/s390/mm/fault.c=408=void do_secure_storage_access(struct pt_regs *regs)\narch/s390/mm/fault.c:409:__context_unsafe(/* folio_walk_end() not instrumented */)\narch/s390/mm/fault.c-410-{\n--\narch/s390/mm/fault.c-464-\t\tfolio_put(folio);\narch/s390/mm/fault.c:465:\t\tfolio_walk_end(\u0026fw, vma);\narch/s390/mm/fault.c-466-\t\tif (rc)\n--\ninclude/linux/pagewalk.h=154=enum folio_walk_level {\n--\ninclude/linux/pagewalk.h-160-/**\ninclude/linux/pagewalk.h:161: * struct folio_walk - folio_walk_start() / folio_walk_end() data\ninclude/linux/pagewalk.h-162- * @page:\texact folio page referenced (if applicable)\n--\ninclude/linux/pagewalk.h=190=struct folio *folio_walk_start(struct folio_walk *fw,\n--\ninclude/linux/pagewalk.h-193-\ninclude/linux/pagewalk.h:194:#define folio_walk_end(__fw, __vma) do { \\\ninclude/linux/pagewalk.h-195-\tspin_unlock((__fw)-\u003eptl); \\\n--\nkernel/events/uprobes.c=499=int uprobe_write(struct arch_uprobe *auprobe, struct vm_area_struct *vma,\n--\nkernel/events/uprobes.c-577-\t\t\tret = __uprobe_write(vma, \u0026fw, folio, insn_vaddr, insn, nbytes, is_register);\nkernel/events/uprobes.c:578:\t\tfolio_walk_end(\u0026fw, vma);\nkernel/events/uprobes.c-579-\t}\n--\nmm/huge_memory.c=4775=static int split_huge_pages_pid(int pid, unsigned long vaddr_start,\n--\nmm/huge_memory.c-4857-\t\tfolio_get(folio);\nmm/huge_memory.c:4858:\t\tfolio_walk_end(\u0026fw, vma);\nmm/huge_memory.c-4859-\n--\nmm/huge_memory.c-4881-next:\nmm/huge_memory.c:4882:\t\tfolio_walk_end(\u0026fw, vma);\nmm/huge_memory.c-4883-\t\tcond_resched();\n--\nmm/ksm.c=831=static struct page *get_mergeable_page(struct ksm_rmap_item *rmap_item)\n--\nmm/ksm.c-852-\t\t}\nmm/ksm.c:853:\t\tfolio_walk_end(\u0026fw, vma);\nmm/ksm.c-854-\t}\n--\nmm/migrate.c=2301=static int add_folio_for_migration(struct mm_struct *mm, const void __user *p,\n--\nmm/migrate.c-2320-\t\t\t\t\t\t\tmigrate_all);\nmm/migrate.c:2321:\t\t\tfolio_walk_end(\u0026fw, vma);\nmm/migrate.c-2322-\t\t} else {\n--\nmm/migrate.c=2459=static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages,\n--\nmm/migrate.c-2486-\t\t\t\terr = folio_nid(folio);\nmm/migrate.c:2487:\t\t\tfolio_walk_end(\u0026fw, vma);\nmm/migrate.c-2488-\t\t} else {\n--\nmm/pagewalk.c=798=int walk_page_mapping(struct address_space *mapping, pgoff_t first_index,\n--\nmm/pagewalk.c-856- * return the folio, making sure that the page table entry referenced by\nmm/pagewalk.c:857: * @addr cannot change until folio_walk_end() was called.\nmm/pagewalk.c-858- *\n--\nmm/pagewalk.c-867- * On success, @fw is filled and the function returns the folio while the PTL\nmm/pagewalk.c:868: * is still held and folio_walk_end() must be called to clean up,\nmm/pagewalk.c-869- * releasing any held locks. The returned folio must *not* be used after the\nmm/pagewalk.c:870: * call to folio_walk_end(), unless a short-term folio reference is taken before\nmm/pagewalk.c-871- * that call.\n--\nmm/rmap.c=2868=struct page *make_device_exclusive(struct mm_struct *mm, unsigned long addr,\n--\nmm/rmap.c-2931-\t\tif (fw_folio)\nmm/rmap.c:2932:\t\t\tfolio_walk_end(\u0026fw, vma);\nmm/rmap.c-2933-\t\tmmu_notifier_invalidate_range_end(\u0026range);\n--\nmm/rmap.c-2958-\nmm/rmap.c:2959:\tfolio_walk_end(\u0026fw, vma);\nmm/rmap.c-2960-\tmmu_notifier_invalidate_range_end(\u0026range);\n"
} |
| 39/3 | 2026/09/11 08:52 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 14395 output: 36 thoughts: 21 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Diving into the Page Walk Implementation** Okay, so I need to refresh my memory on how page walks are handled, specifically the low-level details. The `include/linux/pagewalk.h` file is the obvious place to start. I'm going to jump straight to line 194. It's usually around that point where they define the crucial structures or macros related to traversing the page tables themselves. I'm expecting to find the key data structures for the page walk context or the definitions used to iterate through the page table levels. I'm probably looking at something like a `pgd_t`, `pud_t`, `pmd_t`, or `pte_t` definition, or perhaps the iterators and functions related to fetching the next level. I need to understand what's in play before I go any further into understanding or debugging a specific issue. Let's see what's actually there. |
| 40/3 | 2026/09/11 08:52 | tool | read-file |
0mArgs:{
"File": "include/linux/pagewalk.h",
"FirstLine": 180,
"LineCount": 40
}Results: {
"Contents": " 180:\t\tunion {\n 181:\t\t\tpte_t pte;\n 182:\t\t\tpud_t pud;\n 183:\t\t\tpmd_t pmd;\n 184:\t\t};\n 185:\t\t/* private */\n 186:\t\tspinlock_t *ptl;\n 187:\t\tenum page_walk_lock walk_lock;\n 188:\t};\n 189:\t\n 190:\tstruct folio *folio_walk_start(struct folio_walk *fw,\n 191:\t\t\tstruct vm_area_struct *vma, unsigned long addr,\n 192:\t\t\tfolio_walk_flags_t flags);\n 193:\t\n 194:\t#define folio_walk_end(__fw, __vma) do { \\\n 195:\t\tspin_unlock((__fw)-\u003eptl); \\\n 196:\t\tif (likely((__fw)-\u003elevel == FW_LEVEL_PTE)) \\\n 197:\t\t\tpte_unmap((__fw)-\u003eptep); \\\n 198:\t\tvma_pgtable_walk_end(__vma); \\\n 199:\t} while (0)\n 200:\t\n 201:\t#endif /* _LINUX_PAGEWALK_H */\n"
} |
| 41/3 | 2026/09/11 08:52 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 15006 output: 184 thoughts: 587 Thoughts: **My Analysis of the Patch: KMSAN Applicability**
Okay, let's break this down. First, this patch introduces a `walk_lock` to the `struct folio_walk` and properly initializes it. It also changes some mmap read locking paths in `ksm.c` to use per-vma locking with the appropriate flags. Finally, the `pagewalk.c` code is updated to check the new `fw->walk_lock`.
My immediate concern is always uninitialized memory. Does this introduce any risks in that area? No, because:
* No kernel structures are leaked to userspace. Nothing gets copied out via `copy_to_user` or similar functions.
* All `struct folio_walk` instances are being initialized with `{ .walk_lock = ... }`. This means the compiler is doing its job and zero-initializing the other fields, as it should.
* The `find_mergeable_vma_locked` function either returns a locked VMA or NULL.
* The changes are purely related to locking and page walking – refactoring within KSM and the MM pagewalk.
* Any issues arising from locking or synchronization are going to be caught by LOCKDEP and KASAN, or even general kernel assertions (VM\_BUG\_ON/WARN\_ONCE).
Therefore, I'm confident that this is *not* a `NeedsKMSAN` situation. No uninitialized memory is being used or potentially leaked.
To be absolutely sure, let's verify all the criteria:
1. Kernel structures sent to userspace? No.
2. Conditional logic or branching that depends on potentially uninitialized variables? Nope. All `fw` instances are explicitly initialized.
3. Allocation or initialization of complex data structures where uninitialized fields could be read later? Not here.
4. Bounds checks, lengths, or logic that would allow uninitialized bytes to be read? No dice.
So, let's contrast the relevance of KASAN versus KMSAN.
* KASAN/LOCKDEP: The patch is directly modifying MM locking mechanisms, specifically by introducing per-VMA read locking in KSM and adding checks to pagewalk. Any potential concurrency issues, use-after-free conditions, or locking regressions are squarely within the domain of LOCKDEP and KASAN to detect.
* KMSAN: There are no uninitialized stack/heap variables being read, no information leaks to userspace, and all instances of `struct folio_walk` are explicitly initialized. KMSAN is not necessary here.
Okay, that's my analysis. Let's call `set-results`.
|
| 42/3 | 2026/09/11 08:52 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch refactors page walk locking and transitions KSM from mmap_read_lock to per-VMA read locking (vma_start_read_unlocked/vma_end_read) with lock verification in folio_walk_start(). All local instances of `struct folio_walk` across the codebase are explicitly initialized with designated initializers (`struct folio_walk fw = { .walk_lock = ... };`), which zero-initializes the remaining fields as per C semantics. No kernel buffers or structures are copied to userspace, no uninitialized memory is read or branched upon, and the patch primarily alters locking/synchronization semantics (which are monitored by LOCKDEP and KASAN). Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch refactors page walk locking and transitions KSM from mmap_read_lock to per-VMA read locking (vma_start_read_unlocked/vma_end_read) with lock verification in folio_walk_start(). All local instances of `struct folio_walk` across the codebase are explicitly initialized with designated initializers (`struct folio_walk fw = { .walk_lock = ... };`), which zero-initializes the remaining fields as per C semantics. No kernel buffers or structures are copied to userspace, no uninitialized memory is read or branched upon, and the patch primarily alters locking/synchronization semantics (which are monitored by LOCKDEP and KASAN). Therefore, a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|