AI Trajectory

null

{
  "EnableConfigs": [
    "SPARSEMEM_VMEMMAP",
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "__populate_section_memmap",
    "vmemmap_populate_finalize"
  ],
  "Reasoning": "The patch modifies memory hotplug and initialization logic for RISC-V by adding a TLB flush (vmemmap_populate_finalize) after populating a vmemmap section. This is a functional change in architecture-specific core MM code that is reachable in virtualized environments.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit a87520f840444367d6df6ed2195f8cfb942958bb\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Jun 30 10:29:35 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h\nindex 5d5756bda82e3d..6b000c990ba719 100644\n--- a/arch/riscv/include/asm/pgtable.h\n+++ b/arch/riscv/include/asm/pgtable.h\n@@ -1253,6 +1253,10 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)\n #define TASK_SIZE\tFIXADDR_START\n #endif\n \n+/* Needed on SPARSEMEM_VMEMMAP */\n+#define vmemmap_populate_finalize vmemmap_populate_finalize\n+void __meminit vmemmap_populate_finalize(void);\n+\n #else /* CONFIG_MMU */\n \n #define PAGE_SHARED\t\t__pgprot(0)\ndiff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c\nindex 5b1b3c88b4d130..800cb5c007d102 100644\n--- a/arch/riscv/mm/init.c\n+++ b/arch/riscv/mm/init.c\n@@ -1372,6 +1372,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,\n \t */\n \treturn vmemmap_populate_hugepages(start, end, node, altmap);\n }\n+\n+void __meminit vmemmap_populate_finalize(void)\n+{\n+\t/* Avoid faults on cached non-present TLB entries. */\n+\tmark_new_valid_map();\n+}\n #endif\n \n #if defined(CONFIG_MMU) \u0026\u0026 defined(CONFIG_64BIT)\ndiff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c\nindex 99e2be39671b63..290cafcfd72305 100644\n--- a/mm/sparse-vmemmap.c\n+++ b/mm/sparse-vmemmap.c\n@@ -544,6 +544,12 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,\n \n #endif\n \n+#ifndef vmemmap_populate_finalize\n+static void __meminit vmemmap_populate_finalize(void)\n+{\n+}\n+#endif\n+\n struct page * __meminit __populate_section_memmap(unsigned long pfn,\n \t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n \t\tstruct dev_pagemap *pgmap)\n@@ -564,6 +570,8 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,\n \tif (r \u003c 0)\n \t\treturn NULL;\n \n+\tvmemmap_populate_finalize();\n+\n \treturn pfn_to_page(pfn);\n }\n \n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "SPARSEMEM_VMEMMAP",
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "__populate_section_memmap",
    "vmemmap_populate_finalize"
  ],
  "Reasoning": "The patch modifies memory hotplug and initialization logic for RISC-V by adding a TLB flush (vmemmap_populate_finalize) after populating a vmemmap section. This is a functional change in architecture-specific core MM code that is reachable in virtualized environments.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a '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.

For your convenience, here is the diff of the changes:
commit a87520f840444367d6df6ed2195f8cfb942958bb
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Jun 30 10:29:35 2026 +0000

    syz-cluster: applied patch under review

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 5d5756bda82e3d..6b000c990ba719 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -1253,6 +1253,10 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
 #define TASK_SIZE	FIXADDR_START
 #endif
 
+/* Needed on SPARSEMEM_VMEMMAP */
+#define vmemmap_populate_finalize vmemmap_populate_finalize
+void __meminit vmemmap_populate_finalize(void);
+
 #else /* CONFIG_MMU */
 
 #define PAGE_SHARED		__pgprot(0)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 5b1b3c88b4d130..800cb5c007d102 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -1372,6 +1372,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 	 */
 	return vmemmap_populate_hugepages(start, end, node, altmap);
 }
+
+void __meminit vmemmap_populate_finalize(void)
+{
+	/* Avoid faults on cached non-present TLB entries. */
+	mark_new_valid_map();
+}
 #endif
 
 #if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 99e2be39671b63..290cafcfd72305 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -544,6 +544,12 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
 
 #endif
 
+#ifndef vmemmap_populate_finalize
+static void __meminit vmemmap_populate_finalize(void)
+{
+}
+#endif
+
 struct page * __meminit __populate_section_memmap(unsigned long pfn,
 		unsigned long nr_pages, int nid, struct vmem_altmap *altmap,
 		struct dev_pagemap *pgmap)
@@ -564,6 +570,8 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
 	if (r < 0)
 		return NULL;
 
+	vmemmap_populate_finalize();
+
 	return pfn_to_page(pfn);
 }
 

gemini-3.1-pro-preview

null

null

							input: 2396
							output: 21
							thoughts: 225
						

**Analyzing the vmemmap Population and Finalization**

Okay, so this patch introduces a `vmemmap_populate_finalize` function, called from within `__populate_section_memmap` in `mm/sparse-vmemmap.c`. I need to understand why this finalization step is necessary. Specifically, on RISC-V, it looks like `vmemmap_populate_finalize` is implemented to call `mark_new_valid_map()` in `arch/riscv/mm/init.c`. The comment mentions avoiding faults related to cached, non-present TLB entries. Makes sense. I need to dig a little deeper.

Let's quickly refresh my memory on the call context. I know `__populate_section_memmap` is invoked during memory hotplug or during initialization. Okay, initialization and memory hotplug primarily, so, while memory hotplug is a "feature," this appears to be primarily during init. This has me wondering if there's any immediate fuzzing opportunity here. Memory hotplug can be triggered by a user via sysfs or by adding memory. But the finalization step itself – `vmemmap_populate_finalize` – seems to be just a TLB flush or a similar operation via `mark_new_valid_map()`. I need to confirm that.

So, the key here is `mark_new_valid_map`. I need to figure out the exact behavior of that function, as that's where the critical functionality seems to reside. Knowing this will clarify the significance of this patch and if there are any real security implications.

{
  "Expression": "mark_new_valid_map"
}

{
  "Output": "arch/riscv/include/asm/cacheflush.h=46=extern char _end[];\narch/riscv/include/asm/cacheflush.h:47:static inline void mark_new_valid_map(void)\narch/riscv/include/asm/cacheflush.h-48-{\n--\narch/riscv/include/asm/cacheflush.h=57=static inline void flush_cache_vmap(unsigned long start, unsigned long end)\n--\narch/riscv/include/asm/cacheflush.h-59-\tif (is_vmalloc_or_module_addr((void *)start))\narch/riscv/include/asm/cacheflush.h:60:\t\tmark_new_valid_map();\narch/riscv/include/asm/cacheflush.h-61-}\n--\narch/riscv/include/asm/kfence.h=17=static inline bool kfence_protect_page(unsigned long addr, bool protect)\n--\narch/riscv/include/asm/kfence.h-24-\t\tset_pte(pte, __pte(pte_val(ptep_get(pte)) | _PAGE_PRESENT));\narch/riscv/include/asm/kfence.h:25:\t\tmark_new_valid_map();\narch/riscv/include/asm/kfence.h-26-\t}\n--\narch/riscv/mm/init.c=1376=void __meminit vmemmap_populate_finalize(void)\n--\narch/riscv/mm/init.c-1378-\t/* Avoid faults on cached non-present TLB entries. */\narch/riscv/mm/init.c:1379:\tmark_new_valid_map();\narch/riscv/mm/init.c-1380-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 3425
							output: 21
							thoughts: 180
						

**Analyzing a RISC-V Memory Hotplug Fix**

Okay, so I'm looking at this patch and my initial thought is, `mark_new_valid_map` – I know that flushes the Translation Lookaside Buffer (TLB), or something closely related, right? Then I see that `__populate_section_memmap` is being called during memory hotplug, and immediately I'm thinking about fuzzing this. However, this looks like a very specific architecture fix, specifically for RISC-V.

It looks pretty straightforward: after the `vmemmap_populate()` call within `__populate_section_memmap()`, it just calls `mark_new_valid_map()`. Right, `__populate_section_memmap()` is called when a memory section is populated, which is mostly initialization or during memory hotplug events. Functionally, it's a minor change, a small fix really, but a critical one for RISC-V memory hotplug and initialization.

My primary concern is: is this reachable from userspace? Memory hotplug is triggered via sysfs, so that seems like a potential attack vector. I should check the callers of `__populate_section_memmap` to get a better sense of the code flow and potential vulnerabilities.

{
  "Expression": "__populate_section_memmap"
}

{
  "Output": "include/linux/mm.h=4892=unsigned long section_map_size(void);\ninclude/linux/mm.h:4893:struct page * __populate_section_memmap(unsigned long pfn,\ninclude/linux/mm.h-4894-\t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n--\nmm/sparse-vmemmap.c=548=static void __meminit vmemmap_populate_finalize(void)\n--\nmm/sparse-vmemmap.c-552-\nmm/sparse-vmemmap.c:553:struct page * __meminit __populate_section_memmap(unsigned long pfn,\nmm/sparse-vmemmap.c-554-\t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n--\nmm/sparse-vmemmap.c=688=static struct page * __meminit populate_section_memmap(unsigned long pfn,\n--\nmm/sparse-vmemmap.c-691-{\nmm/sparse-vmemmap.c:692:\tstruct page *page = __populate_section_memmap(pfn, nr_pages, nid, altmap,\nmm/sparse-vmemmap.c-693-\t\t\t\t\t\t      pgmap);\n--\nmm/sparse.c=232=unsigned long __init section_map_size(void)\n--\nmm/sparse.c-236-\nmm/sparse.c:237:struct page __init *__populate_section_memmap(unsigned long pfn,\nmm/sparse.c-238-\t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n--\nmm/sparse.c=298=static void __init sparse_init_nid(int nid, unsigned long pnum_begin,\n--\nmm/sparse.c-320-\t\tif (!preinited_vmemmap_section(ms)) {\nmm/sparse.c:321:\t\t\tmap = __populate_section_memmap(pfn, PAGES_PER_SECTION,\nmm/sparse.c-322-\t\t\t\t\tnid, NULL, NULL);\n"
}

gemini-3.1-pro-preview

null

null

							input: 4438
							output: 20
							thoughts: 60
						

Okay, here's my interpretation of those code snippets, summarized in the first person, as a seasoned kernel memory management expert:

**Understanding the Sparse Vmemmap Initialization**

Alright, so I'm tracing the initialization of the sparse vmemmap, and it looks like the entry points I'm concerned with are `populate_section_memmap` in `mm/sparse-vmemmap.c` and also `sparse_init_nid` in `mm/sparse.c`. Now, `populate_section_memmap` seems to be the crucial function that's being called from within `sparse_add_section`, I see now. This suggests a modular initialization process. Basically, `sparse_add_section` triggers the population of the memmap structure for a particular section, and within it, `populate_section_memmap` handles the actual nitty-gritty of creating and populating those memory maps. Got it. This makes the code more manageable, separating the allocation management from the population. I need to dig into the relationship between `sparse_init_nid` and `populate_section_memmap` to get a full view of the memory layout process.

{
  "Expression": "populate_section_memmap"
}

{
  "Output": "include/linux/mm.h=4892=unsigned long section_map_size(void);\ninclude/linux/mm.h:4893:struct page * __populate_section_memmap(unsigned long pfn,\ninclude/linux/mm.h-4894-\t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n--\nmm/sparse-vmemmap.c=548=static void __meminit vmemmap_populate_finalize(void)\n--\nmm/sparse-vmemmap.c-552-\nmm/sparse-vmemmap.c:553:struct page * __meminit __populate_section_memmap(unsigned long pfn,\nmm/sparse-vmemmap.c-554-\t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n--\nmm/sparse-vmemmap.c=663=static int __meminit section_nr_vmemmap_pages(unsigned long pfn, unsigned long nr_pages,\n--\nmm/sparse-vmemmap.c-687-\nmm/sparse-vmemmap.c:688:static struct page * __meminit populate_section_memmap(unsigned long pfn,\nmm/sparse-vmemmap.c-689-\t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n--\nmm/sparse-vmemmap.c-691-{\nmm/sparse-vmemmap.c:692:\tstruct page *page = __populate_section_memmap(pfn, nr_pages, nid, altmap,\nmm/sparse-vmemmap.c-693-\t\t\t\t\t\t      pgmap);\n--\nmm/sparse-vmemmap.c-699-\nmm/sparse-vmemmap.c:700:static void depopulate_section_memmap(unsigned long pfn, unsigned long nr_pages,\nmm/sparse-vmemmap.c-701-\t\tstruct vmem_altmap *altmap, struct dev_pagemap *pgmap)\n--\nmm/sparse-vmemmap.c=782=static void section_deactivate(unsigned long pfn, unsigned long nr_pages,\n--\nmm/sparse-vmemmap.c-820-\tif (!section_is_early)\nmm/sparse-vmemmap.c:821:\t\tdepopulate_section_memmap(pfn, nr_pages, altmap, pgmap);\nmm/sparse-vmemmap.c-822-\telse if (memmap)\n--\nmm/sparse-vmemmap.c=829=static struct page * __meminit section_activate(int nid, unsigned long pfn,\n--\nmm/sparse-vmemmap.c-862-\nmm/sparse-vmemmap.c:863:\tmemmap = populate_section_memmap(pfn, nr_pages, nid, altmap, pgmap);\nmm/sparse-vmemmap.c-864-\tif (!memmap) {\n--\nmm/sparse.c=232=unsigned long __init section_map_size(void)\n--\nmm/sparse.c-236-\nmm/sparse.c:237:struct page __init *__populate_section_memmap(unsigned long pfn,\nmm/sparse.c-238-\t\tunsigned long nr_pages, int nid, struct vmem_altmap *altmap,\n--\nmm/sparse.c=298=static void __init sparse_init_nid(int nid, unsigned long pnum_begin,\n--\nmm/sparse.c-320-\t\tif (!preinited_vmemmap_section(ms)) {\nmm/sparse.c:321:\t\t\tmap = __populate_section_memmap(pfn, PAGES_PER_SECTION,\nmm/sparse.c-322-\t\t\t\t\tnid, NULL, NULL);\n"
}

gemini-3.1-pro-preview

null

null

							input: 5728
							output: 22
							thoughts: 409
						

**Fuzzing Decision for Memory Hotplug TLB Flush on RISC-V**

Okay, let's break this down. The code in question involves `section_activate`, called from `sparse_add_section`, which in turn is called from `__add_pages`. This whole path relates to memory hotplug, and, crucially, userspace *can* trigger this through sysfs, so it's a realistic execution path. This specific change is a TLB flush on RISC-V after memory hotplug, a targeted architectural adjustment.

The core question is whether fuzzing is justified. Given that it's a functional change, although quite small and specialized, that impacts a core system function triggered by a user action, I need to evaluate this properly. The primary concern is if the code is reachable, and the text says it is in QEMU. That's a good starting point.

The provided guidance states "If it modifies reachable core kernel logic, drivers, or architectures, use your code search tools to verify the code can be executed, then return WorthFuzzing=true." This patch *does* touch architecture-specific code for RISC-V and also interacts with the memory management core, specifically `sparse-vmemmap.c`.

Considering this, I need to focus on reachability. Since QEMU can be used for memory hotplug, the code is reachable. Therefore, I'm confident that fuzzing this is the right decision. This means `WorthFuzzing` should be `true`.

Regarding fuzzing targets, while the patch itself is just a TLB flush, the path *leading* to it is interesting. So the critical sections to focus on are `__populate_section_memmap` and `vmemmap_populate_finalize`. While the latter is just a wrapper for `mark_new_valid_map`, the former is a memory hotplug function and the entry point that makes sense.

Lastly, I'll need to make sure the fuzzing configuration enables `SPARSEMEM_VMEMMAP` and `MEMORY_HOTPLUG`.

{
  "Expression": "SPARSEMEM_VMEMMAP"
}

{
  "Output": "Documentation/mm/memory-model.rst=102=vmemmap\". The selection is made at build time and it is determined by\nDocumentation/mm/memory-model.rst:103:the value of `CONFIG_SPARSEMEM_VMEMMAP`.\nDocumentation/mm/memory-model.rst-104-\n--\nDocumentation/mm/memory-model.rst=134=ZONE_DEVICE\nDocumentation/mm/memory-model.rst-135-===========\nDocumentation/mm/memory-model.rst:136:The `ZONE_DEVICE` facility builds upon `SPARSEMEM_VMEMMAP` to offer\nDocumentation/mm/memory-model.rst-137-`struct page` `mem_map` services for device driver identified physical\n--\nDocumentation/translations/zh_CN/mm/memory-model.rst=63=SPARSEMEM模型将物理内存显示为一个部分的集合。一个区段用mem_section结构\n--\nDocumentation/translations/zh_CN/mm/memory-model.rst-86-通过SPARSEMEM，有两种可能的方式将PFN转换为相应的 `struct page` --\"classic sparse\"和\nDocumentation/translations/zh_CN/mm/memory-model.rst:87: \"sparse vmemmap\"。选择是在构建时进行的，它由 `CONFIG_SPARSEMEM_VMEMMAP` 的\nDocumentation/translations/zh_CN/mm/memory-model.rst-88- 值决定。\n--\narch/arm64/Kconfig=1606=config ARCH_SPARSEMEM_ENABLE\narch/arm64/Kconfig-1607-\tdef_bool y\narch/arm64/Kconfig:1608:\tselect SPARSEMEM_VMEMMAP_ENABLE\narch/arm64/Kconfig-1609-\n--\narch/arm64/mm/mmu.c=2103=static bool can_unmap_without_split(unsigned long pfn, unsigned long nr_pages)\n--\narch/arm64/mm/mmu.c-2119-\t/* PFN range's vmemmap edges are leaf entry aligned */\narch/arm64/mm/mmu.c:2120:\tBUILD_BUG_ON(!IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP));\narch/arm64/mm/mmu.c-2121-\tstart = (unsigned long)pfn_to_page(pfn);\n--\narch/loongarch/Kconfig=775=config ARCH_SPARSEMEM_ENABLE\narch/loongarch/Kconfig-776-\tdef_bool 64BIT\narch/loongarch/Kconfig:777:\tselect SPARSEMEM_VMEMMAP_ENABLE\narch/loongarch/Kconfig-778-\thelp\n--\narch/loongarch/include/asm/sparsemem.h-13-\narch/loongarch/include/asm/sparsemem.h:14:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/loongarch/include/asm/sparsemem.h-15-#define VMEMMAP_SIZE\t(sizeof(struct page) * (1UL \u003c\u003c (cpu_pabits + 1 - PAGE_SHIFT)))\n--\narch/loongarch/mm/init.c=122=void arch_remove_memory(u64 start, u64 size, struct vmem_altmap *altmap,\n--\narch/loongarch/mm/init.c-131-\narch/loongarch/mm/init.c:132:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/loongarch/mm/init.c-133-void __meminit vmemmap_set_pmd(pmd_t *pmd, void *p, int node,\n--\narch/powerpc/Kconfig=794=config ARCH_SPARSEMEM_ENABLE\n--\narch/powerpc/Kconfig-796-\tdepends on PPC64\narch/powerpc/Kconfig:797:\tselect SPARSEMEM_VMEMMAP_ENABLE\narch/powerpc/Kconfig-798-\n--\narch/powerpc/configs/ps3_defconfig=35=CONFIG_BINFMT_MISC=y\narch/powerpc/configs/ps3_defconfig-36-# CONFIG_COMPAT_BRK is not set\narch/powerpc/configs/ps3_defconfig:37:# CONFIG_SPARSEMEM_VMEMMAP is not set\narch/powerpc/configs/ps3_defconfig-38-# CONFIG_COMPACTION is not set\n--\narch/powerpc/include/asm/book3s/64/hash-64k.h-17- */\narch/powerpc/include/asm/book3s/64/hash-64k.h:18:#if defined(CONFIG_SPARSEMEM_VMEMMAP) \u0026\u0026 defined(CONFIG_SPARSEMEM_EXTREME)\narch/powerpc/include/asm/book3s/64/hash-64k.h-19-#define H_MAX_PHYSMEM_BITS\t51\n--\narch/powerpc/include/asm/book3s/64/radix.h-109-\narch/powerpc/include/asm/book3s/64/radix.h:110:#if defined(CONFIG_SPARSEMEM_VMEMMAP) \u0026\u0026 defined(CONFIG_SPARSEMEM_EXTREME)\narch/powerpc/include/asm/book3s/64/radix.h-111-#define R_MAX_PHYSMEM_BITS\t51\n--\narch/powerpc/kexec/vmcore_info.c=6=void arch_crash_save_vmcoreinfo(void)\n--\narch/powerpc/kexec/vmcore_info.c-15-#endif\narch/powerpc/kexec/vmcore_info.c:16:#if defined(CONFIG_PPC64) \u0026\u0026 defined(CONFIG_SPARSEMEM_VMEMMAP)\narch/powerpc/kexec/vmcore_info.c-17-\tVMCOREINFO_SYMBOL(vmemmap_list);\n--\narch/powerpc/mm/book3s64/hash_pgtable.c-26-\narch/powerpc/mm/book3s64/hash_pgtable.c:27:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/hash_pgtable.c-28-/*\n--\narch/powerpc/mm/book3s64/hash_pgtable.c=131=void hash__vmemmap_remove_mapping(unsigned long start,\n--\narch/powerpc/mm/book3s64/hash_pgtable.c-140-#endif\narch/powerpc/mm/book3s64/hash_pgtable.c:141:#endif /* CONFIG_SPARSEMEM_VMEMMAP */\narch/powerpc/mm/book3s64/hash_pgtable.c-142-\n--\narch/powerpc/mm/book3s64/hash_utils.c=1078=static void __init htab_init_page_sizes(void)\n--\narch/powerpc/mm/book3s64/hash_utils.c-1128-\narch/powerpc/mm/book3s64/hash_utils.c:1129:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/hash_utils.c-1130-\t/*\n--\narch/powerpc/mm/book3s64/hash_utils.c-1138-\t\tmmu_vmemmap_psize = mmu_virtual_psize;\narch/powerpc/mm/book3s64/hash_utils.c:1139:#endif /* CONFIG_SPARSEMEM_VMEMMAP */\narch/powerpc/mm/book3s64/hash_utils.c-1140-\n--\narch/powerpc/mm/book3s64/hash_utils.c-1142-\t       \"virtual = %d, io = %d\"\narch/powerpc/mm/book3s64/hash_utils.c:1143:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/hash_utils.c-1144-\t       \", vmemmap = %d\"\n--\narch/powerpc/mm/book3s64/hash_utils.c-1149-\t       mmu_psize_defs[mmu_io_psize].shift\narch/powerpc/mm/book3s64/hash_utils.c:1150:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/hash_utils.c-1151-\t       ,mmu_psize_defs[mmu_vmemmap_psize].shift\n--\narch/powerpc/mm/book3s64/pgtable.c=27=EXPORT_SYMBOL_GPL(mmu_psize_defs);\narch/powerpc/mm/book3s64/pgtable.c-28-\narch/powerpc/mm/book3s64/pgtable.c:29:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/pgtable.c-30-int mmu_vmemmap_psize = MMU_PAGE_4K;\n--\narch/powerpc/mm/book3s64/radix_pgtable.c=723=static void free_pud_table(pud_t *pud_start, p4d_t *p4d)\n--\narch/powerpc/mm/book3s64/radix_pgtable.c-737-\narch/powerpc/mm/book3s64/radix_pgtable.c:738:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/radix_pgtable.c-739-static bool __meminit vmemmap_pmd_is_unused(unsigned long addr, unsigned long end)\n--\narch/powerpc/mm/book3s64/radix_pgtable.c=787=static void __meminit remove_pte_table(pte_t *pte_start, unsigned long addr,\n--\narch/powerpc/mm/book3s64/radix_pgtable.c-808-\t\t}\narch/powerpc/mm/book3s64/radix_pgtable.c:809:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/radix_pgtable.c-810-\t\telse if (!direct \u0026\u0026 vmemmap_page_is_unused(addr, next)) {\n--\narch/powerpc/mm/book3s64/radix_pgtable.c=820=static void __meminit remove_pmd_table(pmd_t *pmd_start, unsigned long addr,\n--\narch/powerpc/mm/book3s64/radix_pgtable.c-842-\t\t\t}\narch/powerpc/mm/book3s64/radix_pgtable.c:843:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/radix_pgtable.c-844-\t\t\telse if (!direct \u0026\u0026 vmemmap_pmd_is_unused(addr, next)) {\n--\narch/powerpc/mm/book3s64/radix_pgtable.c=946=int __meminit radix__remove_section_mapping(unsigned long start, unsigned long end)\n--\narch/powerpc/mm/book3s64/radix_pgtable.c-952-\narch/powerpc/mm/book3s64/radix_pgtable.c:953:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/radix_pgtable.c-954-static int __map_kernel_page_nid(unsigned long ea, unsigned long pa,\n--\narch/powerpc/mm/book3s64/slb.c=467=void slb_initialize(void)\n--\narch/powerpc/mm/book3s64/slb.c-471-\tstatic int slb_encoding_inited;\narch/powerpc/mm/book3s64/slb.c:472:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/slb.c-473-\tunsigned long vmemmap_llp;\n--\narch/powerpc/mm/book3s64/slb.c-480-\tget_paca()-\u003evmalloc_sllp = SLB_VSID_KERNEL | vmalloc_llp;\narch/powerpc/mm/book3s64/slb.c:481:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/slb.c-482-\tvmemmap_llp = mmu_psize_defs[mmu_vmemmap_psize].sllp;\n--\narch/powerpc/mm/book3s64/slb.c-487-\t\tpr_devel(\"SLB: io      LLP = %04lx\\n\", io_llp);\narch/powerpc/mm/book3s64/slb.c:488:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/slb.c-489-\t\tpr_devel(\"SLB: vmemmap LLP = %04lx\\n\", vmemmap_llp);\n--\narch/powerpc/mm/book3s64/slb.c=662=static long slb_allocate_kernel(unsigned long ea, unsigned long id)\n--\narch/powerpc/mm/book3s64/slb.c-675-\narch/powerpc/mm/book3s64/slb.c:676:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/book3s64/slb.c-677-\t} else if (id == VMEMMAP_REGION_ID) {\n--\narch/powerpc/mm/init_64.c-66-\narch/powerpc/mm/init_64.c:67:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/init_64.c-68-/*\n--\narch/powerpc/mm/init_64.c=378=void __ref vmemmap_free(unsigned long start, unsigned long end,\n--\narch/powerpc/mm/init_64.c-389-\narch/powerpc/mm/init_64.c:390:#endif /* CONFIG_SPARSEMEM_VMEMMAP */\narch/powerpc/mm/init_64.c-391-\n--\narch/powerpc/mm/nohash/book3e_pgtable.c-16-\narch/powerpc/mm/nohash/book3e_pgtable.c:17:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/powerpc/mm/nohash/book3e_pgtable.c-18-/*\n--\narch/powerpc/mm/nohash/book3e_pgtable.c=48=void vmemmap_remove_mapping(unsigned long start,\n--\narch/powerpc/mm/nohash/book3e_pgtable.c-52-#endif\narch/powerpc/mm/nohash/book3e_pgtable.c:53:#endif /* CONFIG_SPARSEMEM_VMEMMAP */\narch/powerpc/mm/nohash/book3e_pgtable.c-54-\n--\narch/powerpc/mm/ptdump/hashpagetable.c=490=static void walk_vmemmap(struct pg_state *st)\n--\narch/powerpc/mm/ptdump/hashpagetable.c-493-\narch/powerpc/mm/ptdump/hashpagetable.c:494:\tif (!IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))\narch/powerpc/mm/ptdump/hashpagetable.c-495-\t\treturn;\n--\narch/riscv/Kconfig=13=config RISCV\n--\narch/riscv/Kconfig-22-\tselect ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE \u0026\u0026 MIGRATION\narch/riscv/Kconfig:23:\tselect ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM_VMEMMAP\narch/riscv/Kconfig-24-\tselect ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS \u003e 2\n--\narch/riscv/Kconfig=308=config ARCH_SPARSEMEM_ENABLE\n--\narch/riscv/Kconfig-311-\tselect SPARSEMEM_STATIC if 32BIT \u0026\u0026 SPARSEMEM\narch/riscv/Kconfig:312:\tselect SPARSEMEM_VMEMMAP_ENABLE if 64BIT\narch/riscv/Kconfig-313-\n--\narch/riscv/include/asm/pgtable.h-91- * Define vmemmap for pfn_to_page \u0026 page_to_pfn calls. Needed if kernel\narch/riscv/include/asm/pgtable.h:92: * is configured with CONFIG_SPARSEMEM_VMEMMAP enabled.\narch/riscv/include/asm/pgtable.h-93- */\n--\narch/riscv/include/asm/pgtable.h-98-#define DIRECT_MAP_PHYSMEM_END (phys_ram_base + KERN_VIRT_SIZE - 1)\narch/riscv/include/asm/pgtable.h:99:#elif defined(CONFIG_SPARSEMEM_VMEMMAP)\narch/riscv/include/asm/pgtable.h-100-#define DIRECT_MAP_PHYSMEM_END \\\n--\narch/riscv/include/asm/pgtable.h=1206=static inline pte_t pte_swp_clear_exclusive(pte_t pte)\n--\narch/riscv/include/asm/pgtable.h-1255-\narch/riscv/include/asm/pgtable.h:1256:/* Needed on SPARSEMEM_VMEMMAP */\narch/riscv/include/asm/pgtable.h-1257-#define vmemmap_populate_finalize vmemmap_populate_finalize\n--\narch/riscv/mm/init.c=60=EXPORT_SYMBOL(phys_ram_base);\narch/riscv/mm/init.c-61-\narch/riscv/mm/init.c:62:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/riscv/mm/init.c-63-#define VMEMMAP_ADDR_ALIGN\tmax(1ULL \u003c\u003c SECTION_SIZE_BITS, \\\n--\narch/riscv/mm/init.c=207=static void __init setup_bootmem(void)\n--\narch/riscv/mm/init.c-233-\tphys_ram_base = memblock_start_of_DRAM() \u0026 PMD_MASK;\narch/riscv/mm/init.c:234:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/riscv/mm/init.c-235-\tvmemmap_start_pfn = round_down(phys_ram_base, VMEMMAP_ADDR_ALIGN) \u003e\u003e PAGE_SHIFT;\n--\narch/riscv/mm/init.c=1349=void __init misc_mem_init(void)\n--\narch/riscv/mm/init.c-1352-\tarch_numa_init();\narch/riscv/mm/init.c:1353:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/riscv/mm/init.c-1354-\t/* The entire VMEMMAP region has been populated. Flush TLB for this region */\n--\narch/riscv/mm/init.c-1360-\narch/riscv/mm/init.c:1361:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/riscv/mm/init.c-1362-int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,\n--\narch/riscv/mm/init.c-1367-\t/*\narch/riscv/mm/init.c:1368:\t * Note that SPARSEMEM_VMEMMAP is only selected for rv64 and that we\narch/riscv/mm/init.c-1369-\t * can't use hugepage mappings for 2-level page table because in case of\n--\narch/riscv/mm/ptdump.c=61=enum address_markers_idx {\n--\narch/riscv/mm/ptdump.c-65-\tPCI_IO_END_NR,\narch/riscv/mm/ptdump.c:66:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/riscv/mm/ptdump.c-67-\tVMEMMAP_START_NR,\n--\narch/riscv/mm/ptdump.c=84=static struct addr_marker address_markers[] = {\n--\narch/riscv/mm/ptdump.c-88-\t{0, \"PCI I/O end\"},\narch/riscv/mm/ptdump.c:89:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/riscv/mm/ptdump.c-90-\t{0, \"vmemmap start\"},\n--\narch/riscv/mm/ptdump.c=423=static int __init ptdump_init(void)\n--\narch/riscv/mm/ptdump.c-430-\taddress_markers[PCI_IO_END_NR].start_address = PCI_IO_END;\narch/riscv/mm/ptdump.c:431:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/riscv/mm/ptdump.c-432-\taddress_markers[VMEMMAP_START_NR].start_address = VMEMMAP_START;\n--\narch/s390/Kconfig=710=config ARCH_SPARSEMEM_ENABLE\narch/s390/Kconfig-711-\tdef_bool y\narch/s390/Kconfig:712:\tselect SPARSEMEM_VMEMMAP_ENABLE\narch/s390/Kconfig-713-\n--\narch/sparc/Kconfig=272=config ARCH_SPARSEMEM_ENABLE\narch/sparc/Kconfig-273-\tdef_bool y if SPARC64\narch/sparc/Kconfig:274:\tselect SPARSEMEM_VMEMMAP_ENABLE\narch/sparc/Kconfig-275-\n--\narch/sparc/kernel/ktlb.S=171=kvmap_dtlb_load:\n--\narch/sparc/kernel/ktlb.S-195-\narch/sparc/kernel/ktlb.S:196:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/sparc/kernel/ktlb.S-197-kvmap_vmemmap:\n--\narch/sparc/kernel/ktlb.S=202=kvmap_dtlb_nonlinear:\n--\narch/sparc/kernel/ktlb.S-208-\narch/sparc/kernel/ktlb.S:209:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/sparc/kernel/ktlb.S-210-\t/* Do not use the TSB for vmemmap.  */\n--\narch/sparc/mm/init_64.c=2542=EXPORT_SYMBOL(_PAGE_CACHE);\narch/sparc/mm/init_64.c-2543-\narch/sparc/mm/init_64.c:2544:#ifdef CONFIG_SPARSEMEM_VMEMMAP\narch/sparc/mm/init_64.c-2545-void __meminit vmemmap_set_pmd(pmd_t *pmd, void *p, int node,\n--\narch/sparc/mm/init_64.c=2562=int __meminit vmemmap_populate(unsigned long vstart, unsigned long vend,\n--\narch/sparc/mm/init_64.c-2566-}\narch/sparc/mm/init_64.c:2567:#endif /* CONFIG_SPARSEMEM_VMEMMAP */\narch/sparc/mm/init_64.c-2568-\n--\narch/x86/Kconfig=1557=config ARCH_SPARSEMEM_ENABLE\n--\narch/x86/Kconfig-1559-\tselect SPARSEMEM_STATIC if X86_32\narch/x86/Kconfig:1560:\tselect SPARSEMEM_VMEMMAP_ENABLE if X86_64\narch/x86/Kconfig-1561-\n--\narch/x86/entry/vdso/vdso32/fake_32bit_build.h-12-#undef CONFIG_ILLEGAL_POINTER_VALUE\narch/x86/entry/vdso/vdso32/fake_32bit_build.h:13:#undef CONFIG_SPARSEMEM_VMEMMAP\narch/x86/entry/vdso/vdso32/fake_32bit_build.h-14-#undef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP\n--\nfs/Kconfig=277=config HUGETLB_PAGE_OPTIMIZE_VMEMMAP\n--\nfs/Kconfig-279-\tdepends on ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP\nfs/Kconfig:280:\tdepends on SPARSEMEM_VMEMMAP\nfs/Kconfig:281:\tselect SPARSEMEM_VMEMMAP_PREINIT if ARCH_WANT_HUGETLB_VMEMMAP_PREINIT\nfs/Kconfig-282-\n--\nfs/proc/kcore.c=142=static int kcore_ram_list(struct list_head *head)\n--\nfs/proc/kcore.c-157-\nfs/proc/kcore.c:158:#ifdef CONFIG_SPARSEMEM_VMEMMAP\nfs/proc/kcore.c-159-/* calculate vmemmap's address from given system ram pfn and register it */\n--\ninclude/asm-generic/memory_model.h=26=static inline int pfn_valid(unsigned long pfn)\n--\ninclude/asm-generic/memory_model.h-42-\ninclude/asm-generic/memory_model.h:43:#elif defined(CONFIG_SPARSEMEM_VMEMMAP)\ninclude/asm-generic/memory_model.h-44-\n--\ninclude/linux/mm.h=211=extern unsigned long sysctl_admin_reserve_kbytes;\ninclude/linux/mm.h-212-\ninclude/linux/mm.h:213:#if defined(CONFIG_SPARSEMEM) \u0026\u0026 !defined(CONFIG_SPARSEMEM_VMEMMAP)\ninclude/linux/mm.h-214-bool page_range_contiguous(const struct page *page, unsigned long nr_pages);\n--\ninclude/linux/mm.h=2265=static inline bool is_nommu_shared_vma_flags(const vma_flags_t *flags)\n--\ninclude/linux/mm.h-2270-\ninclude/linux/mm.h:2271:#if defined(CONFIG_SPARSEMEM) \u0026\u0026 !defined(CONFIG_SPARSEMEM_VMEMMAP)\ninclude/linux/mm.h-2272-#define SECTION_IN_PAGE_FLAGS\n--\ninclude/linux/mm.h=4918=void vmemmap_free(unsigned long start, unsigned long end,\n--\ninclude/linux/mm.h-4921-\ninclude/linux/mm.h:4922:#ifdef CONFIG_SPARSEMEM_VMEMMAP\ninclude/linux/mm.h-4923-static inline unsigned long vmem_altmap_offset(const struct vmem_altmap *altmap)\n--\ninclude/linux/mmzone.h-70-#define MAX_FOLIO_ORDER\t\tMAX_PAGE_ORDER\ninclude/linux/mmzone.h:71:#elif defined(CONFIG_SPARSEMEM) \u0026\u0026 !defined(CONFIG_SPARSEMEM_VMEMMAP)\ninclude/linux/mmzone.h-72-/*\n--\ninclude/linux/mmzone.h=1984=struct mem_section_usage {\ninclude/linux/mmzone.h-1985-\tstruct rcu_head rcu;\ninclude/linux/mmzone.h:1986:#ifdef CONFIG_SPARSEMEM_VMEMMAP\ninclude/linux/mmzone.h-1987-\tDECLARE_BITMAP(subsection_map, SUBSECTIONS_PER_SECTION);\n--\ninclude/linux/mmzone.h=2073=enum {\n--\ninclude/linux/mmzone.h-2080-#endif\ninclude/linux/mmzone.h:2081:#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT\ninclude/linux/mmzone.h-2082-\tSECTION_IS_VMEMMAP_PREINIT_BIT,\n--\ninclude/linux/mmzone.h-2093-#endif\ninclude/linux/mmzone.h:2094:#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT\ninclude/linux/mmzone.h-2095-#define SECTION_IS_VMEMMAP_PREINIT\tBIT(SECTION_IS_VMEMMAP_PREINIT_BIT)\n--\ninclude/linux/mmzone.h=2145=static inline int online_device_section(const struct mem_section *section)\n--\ninclude/linux/mmzone.h-2150-\ninclude/linux/mmzone.h:2151:#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT\ninclude/linux/mmzone.h-2152-static inline int preinited_vmemmap_section(const struct mem_section *section)\n--\ninclude/linux/mmzone.h=2192=static inline int subsection_map_index(unsigned long pfn)\n--\ninclude/linux/mmzone.h-2196-\ninclude/linux/mmzone.h:2197:#ifdef CONFIG_SPARSEMEM_VMEMMAP\ninclude/linux/mmzone.h-2198-static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)\n--\ninclude/linux/mmzone.h=2310=static inline unsigned long next_valid_pfn(unsigned long pfn, unsigned long end_pfn)\n--\ninclude/linux/mmzone.h-2322-\t */\ninclude/linux/mmzone.h:2323:\tif (pfn \u0026 ~(IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) ?\ninclude/linux/mmzone.h-2324-\t\t   PAGE_SUBSECTION_MASK : PAGE_SECTION_MASK))\n--\ninclude/linux/page-flags-layout.h-51- */\ninclude/linux/page-flags-layout.h:52:#if defined(CONFIG_SPARSEMEM) \u0026\u0026 !defined(CONFIG_SPARSEMEM_VMEMMAP)\ninclude/linux/page-flags-layout.h-53-#define SECTIONS_WIDTH\t\tSECTIONS_SHIFT\n--\ninclude/linux/page-flags-layout.h-60-#define NODES_WIDTH\t\tNODES_SHIFT\ninclude/linux/page-flags-layout.h:61:#elif defined(CONFIG_SPARSEMEM_VMEMMAP)\ninclude/linux/page-flags-layout.h-62-#error \"Vmemmap: No space for nodes field in page flags\"\n--\ninclude/linux/page-flags.h-90- * SPARSEMEM section (for variants of SPARSEMEM that require section ids like\ninclude/linux/page-flags.h:91: * SPARSEMEM_EXTREME with !SPARSEMEM_VMEMMAP).\ninclude/linux/page-flags.h-92- */\n--\nkernel/vmcore_info.c=140=static int __init crash_save_vmcoreinfo_init(void)\n--\nkernel/vmcore_info.c-175-#endif\nkernel/vmcore_info.c:176:#ifdef CONFIG_SPARSEMEM_VMEMMAP\nkernel/vmcore_info.c-177-\tVMCOREINFO_SYMBOL_ARRAY(vmemmap);\n--\nmm/Kconfig=451=config SPARSEMEM_EXTREME\n--\nmm/Kconfig-454-\nmm/Kconfig:455:config SPARSEMEM_VMEMMAP_ENABLE\nmm/Kconfig-456-\tbool\nmm/Kconfig-457-\nmm/Kconfig:458:config SPARSEMEM_VMEMMAP\nmm/Kconfig-459-\tdef_bool y\nmm/Kconfig:460:\tdepends on SPARSEMEM \u0026\u0026 SPARSEMEM_VMEMMAP_ENABLE\nmm/Kconfig-461-\thelp\nmm/Kconfig:462:\t  SPARSEMEM_VMEMMAP uses a virtually mapped memmap to optimise\nmm/Kconfig-463-\t  pfn_to_page and page_to_pfn operations.  This is the most\n--\nmm/Kconfig-465-\nmm/Kconfig:466:config SPARSEMEM_VMEMMAP_PREINIT\nmm/Kconfig-467-\tbool\n--\nmm/Kconfig=523=menuconfig MEMORY_HOTPLUG\n--\nmm/Kconfig-525-\tselect MEMORY_ISOLATION\nmm/Kconfig:526:\tdepends on SPARSEMEM_VMEMMAP\nmm/Kconfig-527-\tdepends on ARCH_ENABLE_MEMORY_HOTPLUG\n--\nmm/Kconfig=597=config MHP_MEMMAP_ON_MEMORY\nmm/Kconfig-598-\tdef_bool y\nmm/Kconfig:599:\tdepends on MEMORY_HOTPLUG \u0026\u0026 SPARSEMEM_VMEMMAP\nmm/Kconfig-600-\tdepends on ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE\n--\nmm/Kconfig=1236=config ZONE_DEVICE\n--\nmm/Kconfig-1239-\tdepends on MEMORY_HOTREMOVE\nmm/Kconfig:1240:\tdepends on SPARSEMEM_VMEMMAP\nmm/Kconfig-1241-\tselect XARRAY_MULTI\n--\nmm/Kconfig=1409=config LRU_GEN\n--\nmm/Kconfig-1412-\t# make sure folio-\u003eflags has enough spare bits\nmm/Kconfig:1413:\tdepends on 64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP\nmm/Kconfig-1414-\thelp\n--\nmm/Makefile=87=obj-$(CONFIG_SPARSEMEM)\t+= sparse.o\nmm/Makefile:88:obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o\nmm/Makefile-89-obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o\n--\nmm/hugetlb_vmemmap.c=704=void hugetlb_vmemmap_optimize_bootmem_folios(struct hstate *h, struct list_head *folio_list)\n--\nmm/hugetlb_vmemmap.c-708-\nmm/hugetlb_vmemmap.c:709:#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT\nmm/hugetlb_vmemmap.c-710-\n--\nmm/hugetlb_vmemmap.h=29=void hugetlb_vmemmap_optimize_bootmem_folios(struct hstate *h, struct list_head *folio_list);\nmm/hugetlb_vmemmap.h:30:#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT\nmm/hugetlb_vmemmap.h-31-void hugetlb_vmemmap_init_early(int nid);\n--\nmm/internal.h=959=static inline void sparse_init_one_section(struct mem_section *ms,\n--\nmm/internal.h-968-\t * We encode the start PFN of the section into the mem_map such that\nmm/internal.h:969:\t * page_to_pfn() on !CONFIG_SPARSEMEM_VMEMMAP can simply subtract it\nmm/internal.h-970-\t * from the page pointer to obtain the PFN.\n--\nmm/internal.h=990=static inline void sparse_init(void) {}\n--\nmm/internal.h-995- */\nmm/internal.h:996:#ifdef CONFIG_SPARSEMEM_VMEMMAP\nmm/internal.h-997-void sparse_init_subsection_map(unsigned long pfn, unsigned long nr_pages);\n--\nmm/internal.h=999=static inline void sparse_init_subsection_map(unsigned long pfn,\n--\nmm/internal.h-1002-}\nmm/internal.h:1003:#endif /* CONFIG_SPARSEMEM_VMEMMAP */\nmm/internal.h-1004-\n--\nmm/memblock.c=2183=static void __init free_unused_memmap(void)\n--\nmm/memblock.c-2188-\tif (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) ||\nmm/memblock.c:2189:\t    IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))\nmm/memblock.c-2190-\t\treturn;\n--\nmm/sparse-vmemmap.c=553=struct page * __meminit __populate_section_memmap(unsigned long pfn,\n--\nmm/sparse-vmemmap.c-577-\nmm/sparse-vmemmap.c:578:#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT\nmm/sparse-vmemmap.c-579-/*\n--\nmm/sparse.c=220=size_t mem_section_usage_size(void)\n--\nmm/sparse.c-224-\nmm/sparse.c:225:#ifdef CONFIG_SPARSEMEM_VMEMMAP\nmm/sparse.c-226-unsigned long __init section_map_size(void)\n--\nmm/sparse.c=237=struct page __init *__populate_section_memmap(unsigned long pfn,\n--\nmm/sparse.c-251-}\nmm/sparse.c:252:#endif /* !CONFIG_SPARSEMEM_VMEMMAP */\nmm/sparse.c-253-\n--\nmm/util.c=1567=unsigned int folio_pte_batch(struct folio *folio, pte_t *ptep, pte_t pte,\n--\nmm/util.c-1573-\nmm/util.c:1574:#if defined(CONFIG_SPARSEMEM) \u0026\u0026 !defined(CONFIG_SPARSEMEM_VMEMMAP)\nmm/util.c-1575-/**\n--\nscripts/gdb/linux/constants.py.in=156=LX_CONFIG(CONFIG_SPARSEMEM_EXTREME)\nscripts/gdb/linux/constants.py.in:157:LX_CONFIG(CONFIG_SPARSEMEM_VMEMMAP)\nscripts/gdb/linux/constants.py.in-158-LX_CONFIG(CONFIG_KASAN)\n--\nscripts/gdb/linux/mm.py=22=class page_ops():\n--\nscripts/gdb/linux/mm.py-24-    def __init__(self):\nscripts/gdb/linux/mm.py:25:        if not constants.LX_CONFIG_SPARSEMEM_VMEMMAP:\nscripts/gdb/linux/mm.py:26:            raise gdb.GdbError('Only support CONFIG_SPARSEMEM_VMEMMAP now')\nscripts/gdb/linux/mm.py-27-        if constants.LX_CONFIG_ARM64 and utils.is_target_arch('aarch64'):\n--\nscripts/gdb/linux/mm.py=34=class x86_page_ops():\n--\nscripts/gdb/linux/mm.py-120-    def pfn_section_valid(self, ms, pfn):\nscripts/gdb/linux/mm.py:121:        if constants.LX_CONFIG_SPARSEMEM_VMEMMAP:\nscripts/gdb/linux/mm.py-122-            idx = self.subsection_map_index(pfn)\n--\nscripts/gdb/linux/mm.py=203=class aarch64_page_ops():\n--\nscripts/gdb/linux/mm.py-324-    def pfn_section_valid(self, ms, pfn):\nscripts/gdb/linux/mm.py:325:        if constants.LX_CONFIG_SPARSEMEM_VMEMMAP:\nscripts/gdb/linux/mm.py-326-            idx = self.subsection_map_index(pfn)\n"
}

gemini-3.1-pro-preview

null

null

							input: 16870
							output: 126
							thoughts: 80
						

**My Assessment of the Potential Fuzzing Targets**

Okay, so I've been looking at this system and it seems like we've got a promising avenue for fuzzing. I see `SPARSEMEM_VMEMMAP` and `MEMORY_HOTPLUG` as key configuration options. Given these options, my gut tells me this is worth the effort, so I'm going to set `WorthFuzzing` to `true`. This suggests there's a good chance to find some interesting bugs.

Specifically, I need to focus my fuzzing efforts on these symbols: `__populate_section_memmap` and `vmemmap_populate_finalize`. These are likely where the action is, related to the virtual memory map population and finalization, which are often sources of memory management bugs.

And of course, for this to be effective, I need to make sure those two configurations, `SPARSEMEM_VMEMMAP` and `MEMORY_HOTPLUG`, are enabled during the fuzzing process. Those are the enabling conditions.

{
  "EnableConfigs": [
    "SPARSEMEM_VMEMMAP",
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "__populate_section_memmap",
    "vmemmap_populate_finalize"
  ],
  "Reasoning": "The patch modifies memory hotplug and initialization logic for RISC-V by adding a TLB flush (vmemmap_populate_finalize) after populating a vmemmap section. This is a functional change in architecture-specific core MM code that is reachable in virtualized environments.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "SPARSEMEM_VMEMMAP",
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "__populate_section_memmap",
    "vmemmap_populate_finalize"
  ],
  "Reasoning": "The patch modifies memory hotplug and initialization logic for RISC-V by adding a TLB flush (vmemmap_populate_finalize) after populating a vmemmap section. This is a functional change in architecture-specific core MM code that is reachable in virtualized environments.",
  "WorthFuzzing": true
}