AI Trajectory

null

{
  "EnableConfigs": [
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "online_pages",
    "offline_pages",
    "move_pfn_range_to_zone",
    "remove_pfn_range_from_zone",
    "__add_pages",
    "__remove_pages",
    "adjust_present_page_count"
  ],
  "KMSANReasoning": "The patch modifies memory hotplug and zone contiguous tracking logic by introducing `pages_with_online_memmap` to `struct zone` and updating how `zone_is_contiguous` is evaluated. These changes involve updating counters and boolean flags, and do not introduce new stack or heap allocations that could be left uninitialized. There are no structures copied to user space, so there is no risk of info-leaks. Any bugs introduced by these changes (e.g., incorrect contiguous zone evaluation) would likely result in out-of-bounds accesses, NULL pointer dereferences, or invalid page struct accesses, which are effectively caught by KASAN and standard kernel debugging tools. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch introduces a functional change in how contiguous zones are tracked, replacing an O(N) pageblock iteration with an O(1) check using a new `pages_with_online_memmap` counter in `struct zone`. This counter is updated during memory hotplug and initialization. The changes affect core memory management and memory hotplug logic, which are reachable in virtualized environments and should be fuzzed.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit ed143ca6fafd3825686db2caf91180eb6d0bffb2\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 18 09:06:37 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst\nindex b76183545e5bf..ceea6c8b27cc1 100644\n--- a/Documentation/mm/physical_memory.rst\n+++ b/Documentation/mm/physical_memory.rst\n@@ -483,6 +483,12 @@ General\n   ``present_pages`` should use ``get_online_mems()`` to get a stable value. It\n   is initialized by ``calculate_node_totalpages()``.\n \n+``pages_with_online_memmap``\n+  Pages within the zone that have an online memory map: present pages and\n+  memory holes whose memory map has been initialized and\n+  ``pfn_to_online_page()`` succeeds. See the comment for\n+  ``pages_with_online_memmap`` in ``include/linux/mmzone.h`` for more details.\n+\n ``present_early_pages``\n   The present pages existing within the zone located on memory available since\n   early boot, excluding hotplugged memory. Defined only when\ndiff --git a/drivers/base/memory.c b/drivers/base/memory.c\nindex bcfe2d9f4adbd..97699be9a3578 100644\n--- a/drivers/base/memory.c\n+++ b/drivers/base/memory.c\n@@ -246,6 +246,7 @@ static int memory_block_online(struct memory_block *mem)\n \t\tnr_vmemmap_pages = mem-\u003ealtmap-\u003efree;\n \n \tmem_hotplug_begin();\n+\tclear_zone_contiguous(zone);\n \tif (nr_vmemmap_pages) {\n \t\tret = mhp_init_memmap_on_memory(start_pfn, nr_vmemmap_pages, zone);\n \t\tif (ret)\n@@ -270,6 +271,7 @@ static int memory_block_online(struct memory_block *mem)\n \n \tmem-\u003ezone = zone;\n out:\n+\tset_zone_contiguous(zone);\n \tmem_hotplug_done();\n \treturn ret;\n }\n@@ -295,6 +297,7 @@ static int memory_block_offline(struct memory_block *mem)\n \t\tnr_vmemmap_pages = mem-\u003ealtmap-\u003efree;\n \n \tmem_hotplug_begin();\n+\tclear_zone_contiguous(mem-\u003ezone);\n \tif (nr_vmemmap_pages)\n \t\tadjust_present_page_count(pfn_to_page(start_pfn), mem-\u003egroup,\n \t\t\t\t\t  -nr_vmemmap_pages);\n@@ -312,8 +315,10 @@ static int memory_block_offline(struct memory_block *mem)\n \tif (nr_vmemmap_pages)\n \t\tmhp_deinit_memmap_on_memory(start_pfn, nr_vmemmap_pages);\n \n-\tmem-\u003ezone = NULL;\n out:\n+\tset_zone_contiguous(mem-\u003ezone);\n+\tif (!ret)\n+\t\tmem-\u003ezone = NULL;\n \tmem_hotplug_done();\n \treturn ret;\n }\ndiff --git a/include/linux/mmzone.h b/include/linux/mmzone.h\nindex ca27121871475..58f342de3bacb 100644\n--- a/include/linux/mmzone.h\n+++ b/include/linux/mmzone.h\n@@ -1032,6 +1032,21 @@ struct zone {\n \t * cma pages is present pages that are assigned for CMA use\n \t * (MIGRATE_CMA).\n \t *\n+\t * pages_with_online_memmap tracks pages within the zone that have\n+\t * an online memory map: present pages and memory holes whose\n+\t * memory map has been initialized and pfn_to_online_page()\n+\t * succeeds. When spanned_pages == pages_with_online_memmap,\n+\t * pfn_to_page() can be performed without further checks on any\n+\t * PFN within the zone span.\n+\t *\n+\t * Note: this counter may temporarily undercount when pages with an\n+\t * online memory map exist outside the current zone span. This can\n+\t * only happen during boot, when initializing the memory map of\n+\t * pages that do not fall into any zone span. Growing the zone to\n+\t * cover such pages and later shrinking it back may result in a\n+\t * \"too small\" value. This is safe: it merely prevents detecting a\n+\t * contiguous zone.\n+\t *\n \t * So present_pages may be used by memory hotplug or memory power\n \t * management logic to figure out unmanaged pages by checking\n \t * (present_pages - managed_pages). And managed_pages should be used\n@@ -1056,6 +1071,7 @@ struct zone {\n \tatomic_long_t\t\tmanaged_pages;\n \tunsigned long\t\tspanned_pages;\n \tunsigned long\t\tpresent_pages;\n+\tunsigned long\t\tpages_with_online_memmap;\n #if defined(CONFIG_MEMORY_HOTPLUG)\n \tunsigned long\t\tpresent_early_pages;\n #endif\n@@ -1681,6 +1697,38 @@ static inline bool zone_is_zone_device(const struct zone *zone)\n }\n #endif\n \n+/**\n+ * zone_is_contiguous - test whether a zone is contiguous\n+ * @zone: the zone to test.\n+ *\n+ * In a contiguous zone, it is valid to call pfn_to_page() on any PFN in the\n+ * spanned zone without requiring pfn_valid() or pfn_to_online_page() checks.\n+ *\n+ * Note that missing synchronization with memory offlining makes any PFN\n+ * traversal prone to races.\n+ *\n+ * ZONE_DEVICE zones are always marked non-contiguous.\n+ *\n+ * Return: true if contiguous, otherwise false.\n+ */\n+static inline bool zone_is_contiguous(const struct zone *zone)\n+{\n+\treturn READ_ONCE(zone-\u003econtiguous);\n+}\n+\n+static inline void set_zone_contiguous(struct zone *zone)\n+{\n+\tif (zone_is_zone_device(zone))\n+\t\treturn;\n+\tif (zone-\u003espanned_pages == zone-\u003epages_with_online_memmap)\n+\t\tWRITE_ONCE(zone-\u003econtiguous, true);\n+}\n+\n+static inline void clear_zone_contiguous(struct zone *zone)\n+{\n+\tWRITE_ONCE(zone-\u003econtiguous, false);\n+}\n+\n /*\n  * Returns true if a zone has pages managed by the buddy allocator.\n  * All the reclaim decisions have to use this function rather than\ndiff --git a/mm/internal.h b/mm/internal.h\nindex 181e79f1d6a20..f932b7577c92a 100644\n--- a/mm/internal.h\n+++ b/mm/internal.h\n@@ -805,21 +805,15 @@ extern struct page *__pageblock_pfn_to_page(unsigned long start_pfn,\n static inline struct page *pageblock_pfn_to_page(unsigned long start_pfn,\n \t\t\t\tunsigned long end_pfn, struct zone *zone)\n {\n-\tif (zone-\u003econtiguous)\n+\tif (zone_is_contiguous(zone))\n \t\treturn pfn_to_page(start_pfn);\n \n \treturn __pageblock_pfn_to_page(start_pfn, end_pfn, zone);\n }\n \n-void set_zone_contiguous(struct zone *zone);\n bool pfn_range_intersects_zones(int nid, unsigned long start_pfn,\n \t\t\t   unsigned long nr_pages);\n \n-static inline void clear_zone_contiguous(struct zone *zone)\n-{\n-\tzone-\u003econtiguous = false;\n-}\n-\n extern int __isolate_free_page(struct page *page, unsigned int order);\n extern void __putback_isolated_page(struct page *page, unsigned int order,\n \t\t\t\t    int mt);\ndiff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\nindex 7ac19fab22632..8dbd50d88155a 100644\n--- a/mm/memory_hotplug.c\n+++ b/mm/memory_hotplug.c\n@@ -422,49 +422,39 @@ int __add_pages(int nid, unsigned long pfn, unsigned long nr_pages,\n \treturn err;\n }\n \n-/* find the smallest valid pfn in the range [start_pfn, end_pfn) */\n-static unsigned long find_smallest_section_pfn(int nid, struct zone *zone,\n-\t\t\t\t     unsigned long start_pfn,\n-\t\t\t\t     unsigned long end_pfn)\n+static bool subsection_overlaps_zone(unsigned long pfn, struct zone *zone)\n {\n-\tfor (; start_pfn \u003c end_pfn; start_pfn += PAGES_PER_SUBSECTION) {\n-\t\tif (unlikely(!pfn_to_online_page(start_pfn)))\n-\t\t\tcontinue;\n+\tconst unsigned long start_pfn = ALIGN_DOWN(pfn, PAGES_PER_SUBSECTION);\n+\tconst unsigned long end_pfn = start_pfn + PAGES_PER_SUBSECTION - 1;\n \n-\t\tif (unlikely(pfn_to_nid(start_pfn) != nid))\n-\t\t\tcontinue;\n+\t/* All pages in a subsection are either online or offline. */\n+\tif (unlikely(!pfn_to_online_page(start_pfn)))\n+\t\treturn false;\n \n-\t\tif (zone != page_zone(pfn_to_page(start_pfn)))\n-\t\t\tcontinue;\n+\t/* Checking start+end is sufficient. */\n+\treturn zone == page_zone(pfn_to_page(start_pfn)) ||\n+\t       zone == page_zone(pfn_to_page(end_pfn));\n+}\n \n-\t\treturn start_pfn;\n+/* find the smallest valid pfn in the range [start_pfn, end_pfn) */\n+static unsigned long find_smallest_section_pfn(struct zone *zone,\n+\t\tunsigned long start_pfn, unsigned long end_pfn)\n+{\n+\tfor (; start_pfn \u003c end_pfn; start_pfn += PAGES_PER_SUBSECTION) {\n+\t\tif (subsection_overlaps_zone(start_pfn, zone))\n+\t\t\treturn start_pfn;\n \t}\n-\n \treturn 0;\n }\n \n /* find the biggest valid pfn in the range [start_pfn, end_pfn). */\n-static unsigned long find_biggest_section_pfn(int nid, struct zone *zone,\n-\t\t\t\t    unsigned long start_pfn,\n-\t\t\t\t    unsigned long end_pfn)\n+static unsigned long find_biggest_section_pfn(struct zone *zone,\n+\t\tunsigned long start_pfn, unsigned long end_pfn)\n {\n-\tunsigned long pfn;\n-\n-\t/* pfn is the end pfn of a memory section. */\n-\tpfn = end_pfn - 1;\n-\tfor (; pfn \u003e= start_pfn; pfn -= PAGES_PER_SUBSECTION) {\n-\t\tif (unlikely(!pfn_to_online_page(pfn)))\n-\t\t\tcontinue;\n-\n-\t\tif (unlikely(pfn_to_nid(pfn) != nid))\n-\t\t\tcontinue;\n-\n-\t\tif (zone != page_zone(pfn_to_page(pfn)))\n-\t\t\tcontinue;\n-\n-\t\treturn pfn;\n+\tfor (; end_pfn \u003e= start_pfn; end_pfn -= PAGES_PER_SUBSECTION) {\n+\t\tif (subsection_overlaps_zone(end_pfn - 1, zone))\n+\t\t\treturn end_pfn - 1;\n \t}\n-\n \treturn 0;\n }\n \n@@ -472,7 +462,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,\n \t\t\t     unsigned long end_pfn)\n {\n \tunsigned long pfn;\n-\tint nid = zone_to_nid(zone);\n \n \tif (zone-\u003ezone_start_pfn == start_pfn) {\n \t\t/*\n@@ -481,7 +470,7 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,\n \t\t * In this case, we find second smallest valid mem_section\n \t\t * for shrinking zone.\n \t\t */\n-\t\tpfn = find_smallest_section_pfn(nid, zone, end_pfn,\n+\t\tpfn = find_smallest_section_pfn(zone, end_pfn,\n \t\t\t\t\t\tzone_end_pfn(zone));\n \t\tif (pfn) {\n \t\t\tzone-\u003espanned_pages = zone_end_pfn(zone) - pfn;\n@@ -497,7 +486,7 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,\n \t\t * In this case, we find second biggest valid mem_section for\n \t\t * shrinking zone.\n \t\t */\n-\t\tpfn = find_biggest_section_pfn(nid, zone, zone-\u003ezone_start_pfn,\n+\t\tpfn = find_biggest_section_pfn(zone, zone-\u003ezone_start_pfn,\n \t\t\t\t\t       start_pfn);\n \t\tif (pfn)\n \t\t\tzone-\u003espanned_pages = pfn - zone-\u003ezone_start_pfn + 1;\n@@ -557,18 +546,13 @@ void remove_pfn_range_from_zone(struct zone *zone,\n \n \t/*\n \t * Zone shrinking code cannot properly deal with ZONE_DEVICE. So\n-\t * we will not try to shrink the zones - which is okay as\n-\t * set_zone_contiguous() cannot deal with ZONE_DEVICE either way.\n+\t * we will not try to shrink it.\n \t */\n \tif (zone_is_zone_device(zone))\n \t\treturn;\n \n-\tclear_zone_contiguous(zone);\n-\n \tshrink_zone_span(zone, start_pfn, start_pfn + nr_pages);\n \tupdate_pgdat_span(pgdat);\n-\n-\tset_zone_contiguous(zone);\n }\n \n /**\n@@ -746,8 +730,6 @@ void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,\n \tstruct pglist_data *pgdat = zone-\u003ezone_pgdat;\n \tint nid = pgdat-\u003enode_id;\n \n-\tclear_zone_contiguous(zone);\n-\n \tif (zone_is_empty(zone))\n \t\tinit_currently_empty_zone(zone, start_pfn, nr_pages);\n \tresize_zone_range(zone, start_pfn, nr_pages);\n@@ -775,8 +757,6 @@ void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,\n \tmemmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,\n \t\t\t MEMINIT_HOTPLUG, altmap, migratetype,\n \t\t\t isolate_pageblock);\n-\n-\tset_zone_contiguous(zone);\n }\n \n struct auto_movable_stats {\n@@ -1072,6 +1052,7 @@ void adjust_present_page_count(struct page *page, struct memory_group *group,\n \tif (early_section(__pfn_to_section(page_to_pfn(page))))\n \t\tzone-\u003epresent_early_pages += nr_pages;\n \tzone-\u003epresent_pages += nr_pages;\n+\tzone-\u003epages_with_online_memmap += nr_pages;\n \tzone-\u003ezone_pgdat-\u003enode_present_pages += nr_pages;\n \n \tif (group \u0026\u0026 movable)\ndiff --git a/mm/mm_init.c b/mm/mm_init.c\nindex f1afe023e4e72..d63ee554d7eb8 100644\n--- a/mm/mm_init.c\n+++ b/mm/mm_init.c\n@@ -799,6 +799,28 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)\n \t__init_deferred_page(pfn, nid);\n }\n \n+#ifdef CONFIG_SPARSEMEM_VMEMMAP\n+static bool __init unavailable_pfn_is_online(unsigned long pfn,\n+\t\t\t\t\t     unsigned long *last_subsection,\n+\t\t\t\t\t     bool *is_online)\n+{\n+\tunsigned long subsection = pfn \u0026 PAGE_SUBSECTION_MASK;\n+\n+\tif (subsection != *last_subsection) {\n+\t\t*is_online = !!pfn_to_online_page(pfn);\n+\t\t*last_subsection = subsection;\n+\t}\n+\treturn *is_online;\n+}\n+#else\n+static inline bool unavailable_pfn_is_online(unsigned long pfn,\n+\t\t\t\t\t     unsigned long *last_subsection,\n+\t\t\t\t\t     bool *is_online)\n+{\n+\treturn true;\n+}\n+#endif\n+\n /*\n  * Only struct pages that correspond to ranges defined by memblock.memory\n  * are zeroed and initialized by going through __init_single_page() during\n@@ -822,22 +844,27 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)\n  *   zone/node above the hole except for the trailing pages in the last\n  *   section that will be appended to the zone/node below.\n  */\n-static void __init init_unavailable_range(unsigned long spfn,\n-\t\t\t\t\t  unsigned long epfn,\n-\t\t\t\t\t  int zone, int node)\n+static unsigned long __init init_unavailable_range(unsigned long spfn,\n+\t\t\t\t\t\t   unsigned long epfn,\n+\t\t\t\t\t\t   int zone, int node)\n {\n \tunsigned long pfn;\n-\tu64 pgcnt = 0;\n+\tu64 pgcnt = 0, online_pgcnt = 0;\n+\tunsigned long last_subsection = -1;\n+\tbool is_online = false;\n \n \tfor_each_valid_pfn(pfn, spfn, epfn) {\n \t\t__init_single_page(pfn_to_page(pfn), pfn, zone, node);\n \t\t__SetPageReserved(pfn_to_page(pfn));\n+\t\tif (unavailable_pfn_is_online(pfn, \u0026last_subsection, \u0026is_online))\n+\t\t\tonline_pgcnt++;\n \t\tpgcnt++;\n \t}\n \n \tif (pgcnt)\n \t\tpr_info(\"On node %d, zone %s: %lld pages in unavailable ranges\\n\",\n \t\t\tnode, zone_names[zone], pgcnt);\n+\treturn online_pgcnt;\n }\n \n /*\n@@ -934,9 +961,21 @@ static void __init memmap_init_zone_range(struct zone *zone,\n \n \tmemmap_init_range(end_pfn - start_pfn, nid, zone_id, start_pfn,\n \t\t\t  zone_end_pfn, MEMINIT_EARLY, NULL, mt, false);\n+\tzone-\u003epages_with_online_memmap += end_pfn - start_pfn;\n+\n+\tif (*hole_pfn \u003c start_pfn) {\n+\t\tunsigned long hole_start_pfn = *hole_pfn;\n+\t\tunsigned long pgcnt;\n \n-\tif (*hole_pfn \u003c start_pfn)\n-\t\tinit_unavailable_range(*hole_pfn, start_pfn, zone_id, nid);\n+\t\tif (hole_start_pfn \u003c zone_start_pfn) {\n+\t\t\tinit_unavailable_range(hole_start_pfn, zone_start_pfn,\n+\t\t\t\t\t       zone_id, nid);\n+\t\t\thole_start_pfn = zone_start_pfn;\n+\t\t}\n+\t\tpgcnt = init_unavailable_range(hole_start_pfn, start_pfn,\n+\t\t\t\t\t       zone_id, nid);\n+\t\tzone-\u003epages_with_online_memmap += pgcnt;\n+\t}\n \n \t*hole_pfn = end_pfn;\n }\n@@ -2195,28 +2234,6 @@ void __init init_cma_pageblock(struct page *page)\n }\n #endif\n \n-void set_zone_contiguous(struct zone *zone)\n-{\n-\tunsigned long block_start_pfn = zone-\u003ezone_start_pfn;\n-\tunsigned long block_end_pfn;\n-\n-\tblock_end_pfn = pageblock_end_pfn(block_start_pfn);\n-\tfor (; block_start_pfn \u003c zone_end_pfn(zone);\n-\t\t\tblock_start_pfn = block_end_pfn,\n-\t\t\t block_end_pfn += pageblock_nr_pages) {\n-\n-\t\tblock_end_pfn = min(block_end_pfn, zone_end_pfn(zone));\n-\n-\t\tif (!__pageblock_pfn_to_page(block_start_pfn,\n-\t\t\t\t\t     block_end_pfn, zone))\n-\t\t\treturn;\n-\t\tcond_resched();\n-\t}\n-\n-\t/* We confirm that there is no hole */\n-\tzone-\u003econtiguous = true;\n-}\n-\n /*\n  * Check if a PFN range intersects multiple zones on one or more\n  * NUMA nodes. Specify the @nid argument if it is known that this\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "online_pages",
    "offline_pages",
    "move_pfn_range_to_zone",
    "remove_pfn_range_from_zone",
    "__add_pages",
    "__remove_pages",
    "adjust_present_page_count"
  ],
  "Reasoning": "The patch introduces a functional change in how contiguous zones are tracked, replacing an O(N) pageblock iteration with an O(1) check using a new `pages_with_online_memmap` counter in `struct zone`. This counter is updated during memory hotplug and initialization. The changes affect core memory management and memory hotplug logic, which are reachable in virtualized environments and should be fuzzed.",
  "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).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
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.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. 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 ed143ca6fafd3825686db2caf91180eb6d0bffb2
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 18 09:06:37 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst
index b76183545e5bf..ceea6c8b27cc1 100644
--- a/Documentation/mm/physical_memory.rst
+++ b/Documentation/mm/physical_memory.rst
@@ -483,6 +483,12 @@ General
   ``present_pages`` should use ``get_online_mems()`` to get a stable value. It
   is initialized by ``calculate_node_totalpages()``.
 
+``pages_with_online_memmap``
+  Pages within the zone that have an online memory map: present pages and
+  memory holes whose memory map has been initialized and
+  ``pfn_to_online_page()`` succeeds. See the comment for
+  ``pages_with_online_memmap`` in ``include/linux/mmzone.h`` for more details.
+
 ``present_early_pages``
   The present pages existing within the zone located on memory available since
   early boot, excluding hotplugged memory. Defined only when
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bcfe2d9f4adbd..97699be9a3578 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -246,6 +246,7 @@ static int memory_block_online(struct memory_block *mem)
 		nr_vmemmap_pages = mem->altmap->free;
 
 	mem_hotplug_begin();
+	clear_zone_contiguous(zone);
 	if (nr_vmemmap_pages) {
 		ret = mhp_init_memmap_on_memory(start_pfn, nr_vmemmap_pages, zone);
 		if (ret)
@@ -270,6 +271,7 @@ static int memory_block_online(struct memory_block *mem)
 
 	mem->zone = zone;
 out:
+	set_zone_contiguous(zone);
 	mem_hotplug_done();
 	return ret;
 }
@@ -295,6 +297,7 @@ static int memory_block_offline(struct memory_block *mem)
 		nr_vmemmap_pages = mem->altmap->free;
 
 	mem_hotplug_begin();
+	clear_zone_contiguous(mem->zone);
 	if (nr_vmemmap_pages)
 		adjust_present_page_count(pfn_to_page(start_pfn), mem->group,
 					  -nr_vmemmap_pages);
@@ -312,8 +315,10 @@ static int memory_block_offline(struct memory_block *mem)
 	if (nr_vmemmap_pages)
 		mhp_deinit_memmap_on_memory(start_pfn, nr_vmemmap_pages);
 
-	mem->zone = NULL;
 out:
+	set_zone_contiguous(mem->zone);
+	if (!ret)
+		mem->zone = NULL;
 	mem_hotplug_done();
 	return ret;
 }
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index ca27121871475..58f342de3bacb 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1032,6 +1032,21 @@ struct zone {
 	 * cma pages is present pages that are assigned for CMA use
 	 * (MIGRATE_CMA).
 	 *
+	 * pages_with_online_memmap tracks pages within the zone that have
+	 * an online memory map: present pages and memory holes whose
+	 * memory map has been initialized and pfn_to_online_page()
+	 * succeeds. When spanned_pages == pages_with_online_memmap,
+	 * pfn_to_page() can be performed without further checks on any
+	 * PFN within the zone span.
+	 *
+	 * Note: this counter may temporarily undercount when pages with an
+	 * online memory map exist outside the current zone span. This can
+	 * only happen during boot, when initializing the memory map of
+	 * pages that do not fall into any zone span. Growing the zone to
+	 * cover such pages and later shrinking it back may result in a
+	 * "too small" value. This is safe: it merely prevents detecting a
+	 * contiguous zone.
+	 *
 	 * So present_pages may be used by memory hotplug or memory power
 	 * management logic to figure out unmanaged pages by checking
 	 * (present_pages - managed_pages). And managed_pages should be used
@@ -1056,6 +1071,7 @@ struct zone {
 	atomic_long_t		managed_pages;
 	unsigned long		spanned_pages;
 	unsigned long		present_pages;
+	unsigned long		pages_with_online_memmap;
 #if defined(CONFIG_MEMORY_HOTPLUG)
 	unsigned long		present_early_pages;
 #endif
@@ -1681,6 +1697,38 @@ static inline bool zone_is_zone_device(const struct zone *zone)
 }
 #endif
 
+/**
+ * zone_is_contiguous - test whether a zone is contiguous
+ * @zone: the zone to test.
+ *
+ * In a contiguous zone, it is valid to call pfn_to_page() on any PFN in the
+ * spanned zone without requiring pfn_valid() or pfn_to_online_page() checks.
+ *
+ * Note that missing synchronization with memory offlining makes any PFN
+ * traversal prone to races.
+ *
+ * ZONE_DEVICE zones are always marked non-contiguous.
+ *
+ * Return: true if contiguous, otherwise false.
+ */
+static inline bool zone_is_contiguous(const struct zone *zone)
+{
+	return READ_ONCE(zone->contiguous);
+}
+
+static inline void set_zone_contiguous(struct zone *zone)
+{
+	if (zone_is_zone_device(zone))
+		return;
+	if (zone->spanned_pages == zone->pages_with_online_memmap)
+		WRITE_ONCE(zone->contiguous, true);
+}
+
+static inline void clear_zone_contiguous(struct zone *zone)
+{
+	WRITE_ONCE(zone->contiguous, false);
+}
+
 /*
  * Returns true if a zone has pages managed by the buddy allocator.
  * All the reclaim decisions have to use this function rather than
diff --git a/mm/internal.h b/mm/internal.h
index 181e79f1d6a20..f932b7577c92a 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -805,21 +805,15 @@ extern struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
 static inline struct page *pageblock_pfn_to_page(unsigned long start_pfn,
 				unsigned long end_pfn, struct zone *zone)
 {
-	if (zone->contiguous)
+	if (zone_is_contiguous(zone))
 		return pfn_to_page(start_pfn);
 
 	return __pageblock_pfn_to_page(start_pfn, end_pfn, zone);
 }
 
-void set_zone_contiguous(struct zone *zone);
 bool pfn_range_intersects_zones(int nid, unsigned long start_pfn,
 			   unsigned long nr_pages);
 
-static inline void clear_zone_contiguous(struct zone *zone)
-{
-	zone->contiguous = false;
-}
-
 extern int __isolate_free_page(struct page *page, unsigned int order);
 extern void __putback_isolated_page(struct page *page, unsigned int order,
 				    int mt);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 7ac19fab22632..8dbd50d88155a 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -422,49 +422,39 @@ int __add_pages(int nid, unsigned long pfn, unsigned long nr_pages,
 	return err;
 }
 
-/* find the smallest valid pfn in the range [start_pfn, end_pfn) */
-static unsigned long find_smallest_section_pfn(int nid, struct zone *zone,
-				     unsigned long start_pfn,
-				     unsigned long end_pfn)
+static bool subsection_overlaps_zone(unsigned long pfn, struct zone *zone)
 {
-	for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SUBSECTION) {
-		if (unlikely(!pfn_to_online_page(start_pfn)))
-			continue;
+	const unsigned long start_pfn = ALIGN_DOWN(pfn, PAGES_PER_SUBSECTION);
+	const unsigned long end_pfn = start_pfn + PAGES_PER_SUBSECTION - 1;
 
-		if (unlikely(pfn_to_nid(start_pfn) != nid))
-			continue;
+	/* All pages in a subsection are either online or offline. */
+	if (unlikely(!pfn_to_online_page(start_pfn)))
+		return false;
 
-		if (zone != page_zone(pfn_to_page(start_pfn)))
-			continue;
+	/* Checking start+end is sufficient. */
+	return zone == page_zone(pfn_to_page(start_pfn)) ||
+	       zone == page_zone(pfn_to_page(end_pfn));
+}
 
-		return start_pfn;
+/* find the smallest valid pfn in the range [start_pfn, end_pfn) */
+static unsigned long find_smallest_section_pfn(struct zone *zone,
+		unsigned long start_pfn, unsigned long end_pfn)
+{
+	for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SUBSECTION) {
+		if (subsection_overlaps_zone(start_pfn, zone))
+			return start_pfn;
 	}
-
 	return 0;
 }
 
 /* find the biggest valid pfn in the range [start_pfn, end_pfn). */
-static unsigned long find_biggest_section_pfn(int nid, struct zone *zone,
-				    unsigned long start_pfn,
-				    unsigned long end_pfn)
+static unsigned long find_biggest_section_pfn(struct zone *zone,
+		unsigned long start_pfn, unsigned long end_pfn)
 {
-	unsigned long pfn;
-
-	/* pfn is the end pfn of a memory section. */
-	pfn = end_pfn - 1;
-	for (; pfn >= start_pfn; pfn -= PAGES_PER_SUBSECTION) {
-		if (unlikely(!pfn_to_online_page(pfn)))
-			continue;
-
-		if (unlikely(pfn_to_nid(pfn) != nid))
-			continue;
-
-		if (zone != page_zone(pfn_to_page(pfn)))
-			continue;
-
-		return pfn;
+	for (; end_pfn >= start_pfn; end_pfn -= PAGES_PER_SUBSECTION) {
+		if (subsection_overlaps_zone(end_pfn - 1, zone))
+			return end_pfn - 1;
 	}
-
 	return 0;
 }
 
@@ -472,7 +462,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 			     unsigned long end_pfn)
 {
 	unsigned long pfn;
-	int nid = zone_to_nid(zone);
 
 	if (zone->zone_start_pfn == start_pfn) {
 		/*
@@ -481,7 +470,7 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 		 * In this case, we find second smallest valid mem_section
 		 * for shrinking zone.
 		 */
-		pfn = find_smallest_section_pfn(nid, zone, end_pfn,
+		pfn = find_smallest_section_pfn(zone, end_pfn,
 						zone_end_pfn(zone));
 		if (pfn) {
 			zone->spanned_pages = zone_end_pfn(zone) - pfn;
@@ -497,7 +486,7 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 		 * In this case, we find second biggest valid mem_section for
 		 * shrinking zone.
 		 */
-		pfn = find_biggest_section_pfn(nid, zone, zone->zone_start_pfn,
+		pfn = find_biggest_section_pfn(zone, zone->zone_start_pfn,
 					       start_pfn);
 		if (pfn)
 			zone->spanned_pages = pfn - zone->zone_start_pfn + 1;
@@ -557,18 +546,13 @@ void remove_pfn_range_from_zone(struct zone *zone,
 
 	/*
 	 * Zone shrinking code cannot properly deal with ZONE_DEVICE. So
-	 * we will not try to shrink the zones - which is okay as
-	 * set_zone_contiguous() cannot deal with ZONE_DEVICE either way.
+	 * we will not try to shrink it.
 	 */
 	if (zone_is_zone_device(zone))
 		return;
 
-	clear_zone_contiguous(zone);
-
 	shrink_zone_span(zone, start_pfn, start_pfn + nr_pages);
 	update_pgdat_span(pgdat);
-
-	set_zone_contiguous(zone);
 }
 
 /**
@@ -746,8 +730,6 @@ void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
 	struct pglist_data *pgdat = zone->zone_pgdat;
 	int nid = pgdat->node_id;
 
-	clear_zone_contiguous(zone);
-
 	if (zone_is_empty(zone))
 		init_currently_empty_zone(zone, start_pfn, nr_pages);
 	resize_zone_range(zone, start_pfn, nr_pages);
@@ -775,8 +757,6 @@ void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
 	memmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,
 			 MEMINIT_HOTPLUG, altmap, migratetype,
 			 isolate_pageblock);
-
-	set_zone_contiguous(zone);
 }
 
 struct auto_movable_stats {
@@ -1072,6 +1052,7 @@ void adjust_present_page_count(struct page *page, struct memory_group *group,
 	if (early_section(__pfn_to_section(page_to_pfn(page))))
 		zone->present_early_pages += nr_pages;
 	zone->present_pages += nr_pages;
+	zone->pages_with_online_memmap += nr_pages;
 	zone->zone_pgdat->node_present_pages += nr_pages;
 
 	if (group && movable)
diff --git a/mm/mm_init.c b/mm/mm_init.c
index f1afe023e4e72..d63ee554d7eb8 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -799,6 +799,28 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)
 	__init_deferred_page(pfn, nid);
 }
 
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+static bool __init unavailable_pfn_is_online(unsigned long pfn,
+					     unsigned long *last_subsection,
+					     bool *is_online)
+{
+	unsigned long subsection = pfn & PAGE_SUBSECTION_MASK;
+
+	if (subsection != *last_subsection) {
+		*is_online = !!pfn_to_online_page(pfn);
+		*last_subsection = subsection;
+	}
+	return *is_online;
+}
+#else
+static inline bool unavailable_pfn_is_online(unsigned long pfn,
+					     unsigned long *last_subsection,
+					     bool *is_online)
+{
+	return true;
+}
+#endif
+
 /*
  * Only struct pages that correspond to ranges defined by memblock.memory
  * are zeroed and initialized by going through __init_single_page() during
@@ -822,22 +844,27 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)
  *   zone/node above the hole except for the trailing pages in the last
  *   section that will be appended to the zone/node below.
  */
-static void __init init_unavailable_range(unsigned long spfn,
-					  unsigned long epfn,
-					  int zone, int node)
+static unsigned long __init init_unavailable_range(unsigned long spfn,
+						   unsigned long epfn,
+						   int zone, int node)
 {
 	unsigned long pfn;
-	u64 pgcnt = 0;
+	u64 pgcnt = 0, online_pgcnt = 0;
+	unsigned long last_subsection = -1;
+	bool is_online = false;
 
 	for_each_valid_pfn(pfn, spfn, epfn) {
 		__init_single_page(pfn_to_page(pfn), pfn, zone, node);
 		__SetPageReserved(pfn_to_page(pfn));
+		if (unavailable_pfn_is_online(pfn, &last_subsection, &is_online))
+			online_pgcnt++;
 		pgcnt++;
 	}
 
 	if (pgcnt)
 		pr_info("On node %d, zone %s: %lld pages in unavailable ranges\n",
 			node, zone_names[zone], pgcnt);
+	return online_pgcnt;
 }
 
 /*
@@ -934,9 +961,21 @@ static void __init memmap_init_zone_range(struct zone *zone,
 
 	memmap_init_range(end_pfn - start_pfn, nid, zone_id, start_pfn,
 			  zone_end_pfn, MEMINIT_EARLY, NULL, mt, false);
+	zone->pages_with_online_memmap += end_pfn - start_pfn;
+
+	if (*hole_pfn < start_pfn) {
+		unsigned long hole_start_pfn = *hole_pfn;
+		unsigned long pgcnt;
 
-	if (*hole_pfn < start_pfn)
-		init_unavailable_range(*hole_pfn, start_pfn, zone_id, nid);
+		if (hole_start_pfn < zone_start_pfn) {
+			init_unavailable_range(hole_start_pfn, zone_start_pfn,
+					       zone_id, nid);
+			hole_start_pfn = zone_start_pfn;
+		}
+		pgcnt = init_unavailable_range(hole_start_pfn, start_pfn,
+					       zone_id, nid);
+		zone->pages_with_online_memmap += pgcnt;
+	}
 
 	*hole_pfn = end_pfn;
 }
@@ -2195,28 +2234,6 @@ void __init init_cma_pageblock(struct page *page)
 }
 #endif
 
-void set_zone_contiguous(struct zone *zone)
-{
-	unsigned long block_start_pfn = zone->zone_start_pfn;
-	unsigned long block_end_pfn;
-
-	block_end_pfn = pageblock_end_pfn(block_start_pfn);
-	for (; block_start_pfn < zone_end_pfn(zone);
-			block_start_pfn = block_end_pfn,
-			 block_end_pfn += pageblock_nr_pages) {
-
-		block_end_pfn = min(block_end_pfn, zone_end_pfn(zone));
-
-		if (!__pageblock_pfn_to_page(block_start_pfn,
-					     block_end_pfn, zone))
-			return;
-		cond_resched();
-	}
-
-	/* We confirm that there is no hole */
-	zone->contiguous = true;
-}
-
 /*
  * Check if a PFN range intersects multiple zones on one or more
  * NUMA nodes. Specify the @nid argument if it is known that this

gemini-3.1-pro-preview

null

null

							input: 7182
							output: 32
							thoughts: 825
						

**Analyzing the Patch for Fuzzing Scope**

Okay, so I need to assess whether this patch introduces functional changes in the kernel that warrant fuzzing attention. Seems like it's touching core memory management and hotplug, which always raises a flag.

Let's break down the changes: From what I'm seeing, this patch is refactoring the tracking of contiguous memory zones. The core of it seems to be optimizing the calculation of `zone->contiguous`. Instead of iterating through pageblocks, it's now using `pages_with_online_memmap` and introducing `zone_is_contiguous()`, `set_zone_contiguous()`, and `clear_zone_contiguous()` which is more efficient, especially in larger zones.

Specifically, I see modifications to:

*   `include/linux/mmzone.h`: Defining the new data and functions.
*   `mm/internal.h`: Replacing some of the current implementations with the new helper functions.
*   `mm/memory_hotplug.c`: Updating some of the hotplug routines and introducing helper functions.
*   `mm/mm_init.c`: Initializing things for hotplug with this updated implementation.
*   `drivers/base/memory.c`: And importantly, changing `memory_block_online` and `memory_block_offline`, which are sysfs exposed, so interesting.

This is a pretty significant shift in how contiguous memory is managed. It's definitely a functional change, aimed at performance, that is worth analyzing from a fuzzing perspective, as even performance-related changes can have subtle effects on the system's behavior. I can see that this is in core memory management and memory hotplug, so this is definitely reachable – especially in virtualized environments like KVM, or even ACPI memory hotplug or virtio-mem.

The `mm_init.c` changes mean this will also be executed at boot time, and that's something else to keep in mind.

My thought process is: what parts are most interesting to look at?

`memory_block_online` and `memory_block_offline` are triggered via sysfs, making them prime fuzzing targets due to their external interface. Also, `__add_pages` and `move_pfn_range_to_zone`, and `adjust_present_page_count`, used in memory hotplug. Let's see if CONFIG_MEMORY_HOTPLUG is set; since this is kernel, it's probably almost always enabled for fuzzing kernels.

Now, I'll need to check the call graph for `memory_block_online`. Since it's a static function, its calling contexts are limited, but finding them is crucial.

{
  "Expression": "memory_block_online",
  "PathPrefix": "drivers/base/memory.c"
}

{
  "Output": "drivers/base/memory.c=215=static inline unsigned long memblk_nr_poison(struct memory_block *mem)\n--\ndrivers/base/memory.c-223- */\ndrivers/base/memory.c:224:static int memory_block_online(struct memory_block *mem)\ndrivers/base/memory.c-225-{\n--\ndrivers/base/memory.c=331=memory_block_action(struct memory_block *mem, unsigned long action)\n--\ndrivers/base/memory.c-336-\tcase MEM_ONLINE:\ndrivers/base/memory.c:337:\t\tret = memory_block_online(mem);\ndrivers/base/memory.c-338-\t\tbreak;\n"
}

gemini-3.1-pro-preview

null

null

							input: 8810
							output: 33
							thoughts: 38
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**Analyzing the Memory Subsystem Online Trigger**

Right, so `memory_block_action` is the function that's ultimately being called here. That's the key operation. And where's it coming from? Ah, it's being triggered via `memory_subsys_online`. Interesting. `memory_subsys_online` itself is initiated by a sysfs event.

So, the causal chain is: sysfs event -> `memory_subsys_online` -> `memory_block_action`. Given that, my focus now needs to be on `memory_subsys_online`. I need to figure out *what* it's doing, *why* it's doing it, and *how* that relates to the sysfs event that triggered it in the first place. Is this a hotplug scenario? Dynamic memory allocation? What's the context? Let's dive into the `memory_subsys_online` code and see what's happening. I need to understand this online procedure to be able to predict what `memory_block_action` will eventually do.

{
  "Expression": "memory_subsys_online",
  "PathPrefix": "drivers/base/memory.c"
}

{
  "Output": "drivers/base/memory.c=53=EXPORT_SYMBOL(sections_per_block);\ndrivers/base/memory.c-54-\ndrivers/base/memory.c:55:static int memory_subsys_online(struct device *dev);\ndrivers/base/memory.c-56-static int memory_subsys_offline(struct device *dev);\n--\ndrivers/base/memory.c=58=static const struct bus_type memory_subsys = {\n--\ndrivers/base/memory.c-60-\t.dev_name = MEMORY_CLASS_NAME,\ndrivers/base/memory.c:61:\t.online = memory_subsys_online,\ndrivers/base/memory.c-62-\t.offline = memory_subsys_offline,\n--\ndrivers/base/memory.c=351=static int memory_block_change_state(struct memory_block *mem,\n--\ndrivers/base/memory.c-368-/* The device lock serializes operations on memory_subsys_[online|offline] */\ndrivers/base/memory.c:369:static int memory_subsys_online(struct device *dev)\ndrivers/base/memory.c-370-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 9441
							output: 32
							thoughts: 26
						

Okay, here's my interpretation of those thoughts, summarized from a first-person expert perspective:

**Investigating a System Trigger**

Alright, so we're dealing with something that's triggered through sysfs – that's the starting point. But, my mind immediately jumps to a specific function: `move_pfn_range_to_zone`. I'm wondering if this is the mechanism being used, or if it's related to the current trigger. I need to figure out how this function interacts with sysfs, or if it's even part of the current problem. Perhaps the question isn't whether it's related, but how.

{
  "Expression": "move_pfn_range_to_zone",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/memory_hotplug.c=711=static inline void section_taint_zone_device(unsigned long pfn)\n--\nmm/memory_hotplug.c-724- */\nmm/memory_hotplug.c:725:void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,\nmm/memory_hotplug.c-726-\t\t\t\t  unsigned long nr_pages,\n--\nmm/memory_hotplug.c=1064=int mhp_init_memmap_on_memory(unsigned long pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-1073-\nmm/memory_hotplug.c:1074:\tmove_pfn_range_to_zone(zone, pfn, nr_pages, NULL, MIGRATE_UNMOVABLE,\nmm/memory_hotplug.c-1075-\t\t\t       false);\n--\nmm/memory_hotplug.c=1118=int online_pages(unsigned long pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-1145-\t/* associate pfn range with the zone */\nmm/memory_hotplug.c:1146:\tmove_pfn_range_to_zone(zone, pfn, nr_pages, NULL, MIGRATE_MOVABLE,\nmm/memory_hotplug.c-1147-\t\t\t       true);\n--\nmm/memory_hotplug.c=2166=void try_offline_node(int nid)\n--\nmm/memory_hotplug.c-2171-\t * If the node still spans pages (especially ZONE_DEVICE), don't\nmm/memory_hotplug.c:2172:\t * offline it. A node spans memory after move_pfn_range_to_zone(),\nmm/memory_hotplug.c-2173-\t * e.g., after the memory block was onlined.\n--\nmm/memremap.c=144=static int pagemap_range(struct dev_pagemap *pgmap, struct mhp_params *params,\n--\nmm/memremap.c-228-\t\tzone = \u0026NODE_DATA(nid)-\u003enode_zones[ZONE_DEVICE];\nmm/memremap.c:229:\t\tmove_pfn_range_to_zone(zone, PHYS_PFN(range-\u003estart),\nmm/memremap.c-230-\t\t\t\tPHYS_PFN(range_len(range)), params-\u003ealtmap,\n"
}

gemini-3.1-pro-preview

null

null

							input: 10269
							output: 25
							thoughts: 105
						

**My Mental Walkthrough of Memory Hotplug Implementation**

Okay, so I'm trying to wrap my head around this memory hotplug implementation. I see `move_pfn_range_to_zone` being called – that's a key function, obviously – and it looks like the main paths to it are through `online_pages` and `mhp_init_memmap_on_memory`. Right, makes sense so far. Now, `online_pages` itself is triggered by `memory_block_online`. Aha! That tells me `memory_block_online` and by extension, its counterpart `memory_block_offline`, are the primary entry points for dealing with this whole hotplug functionality. I need to keep those in mind. Wait a second, didn't I notice that `memory_block_online` is actually declared as `static`? That's… interesting. It limits its visibility within the module, for sure. So, then what about `online_pages` and `offline_pages`? I need to go deeper and understand their role in this. I'm going to have to trace those calls to see how they fit into the bigger picture.

{
  "Expression": "online_pages",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/memory_hotplug.c=633=EXPORT_SYMBOL_GPL(generic_online_page);\nmm/memory_hotplug.c-634-\nmm/memory_hotplug.c:635:static void online_pages_range(unsigned long start_pfn, unsigned long nr_pages)\nmm/memory_hotplug.c-636-{\n--\nmm/memory_hotplug.c=937=static struct zone *auto_movable_zone_for_pfn(int nid,\n--\nmm/memory_hotplug.c-941-{\nmm/memory_hotplug.c:942:\tunsigned long online_pages = 0, max_pages, end_pfn;\nmm/memory_hotplug.c-943-\tstruct page *page;\n--\nmm/memory_hotplug.c-949-\t\tmax_pages = group-\u003es.max_pages;\nmm/memory_hotplug.c:950:\t\tonline_pages = group-\u003epresent_movable_pages;\nmm/memory_hotplug.c-951-\n--\nmm/memory_hotplug.c-973-\t\t\t\tgoto kernel_zone;\nmm/memory_hotplug.c:974:\t\t\tonline_pages += PAGES_PER_SECTION;\nmm/memory_hotplug.c-975-\t\t}\n--\nmm/memory_hotplug.c-982-\t */\nmm/memory_hotplug.c:983:\tnr_pages = max_pages - online_pages;\nmm/memory_hotplug.c-984-\tif (!auto_movable_can_online_movable(NUMA_NO_NODE, group, nr_pages))\n--\nmm/memory_hotplug.c=1095=void mhp_deinit_memmap_on_memory(unsigned long pfn, unsigned long nr_pages)\n--\nmm/memory_hotplug.c-1117- */\nmm/memory_hotplug.c:1118:int online_pages(unsigned long pfn, unsigned long nr_pages,\nmm/memory_hotplug.c-1119-\t\t       struct zone *zone, struct memory_group *group)\n--\nmm/memory_hotplug.c-1180-\nmm/memory_hotplug.c:1181:\tonline_pages_range(pfn, nr_pages);\nmm/memory_hotplug.c-1182-\tadjust_present_page_count(pfn_to_page(pfn), group, nr_pages);\n--\nmm/memory_hotplug.c-1222-failed_addition:\nmm/memory_hotplug.c:1223:\tpr_debug(\"online_pages [mem %#010llx-%#010llx] failed\\n\",\nmm/memory_hotplug.c-1224-\t\t (unsigned long long) pfn \u003c\u003c PAGE_SHIFT,\n--\nmm/memory_hotplug.c=1475=int add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)\n--\nmm/memory_hotplug.c-1553-\nmm/memory_hotplug.c:1554:\t/* device_online() will take the lock when calling online_pages() */\nmm/memory_hotplug.c-1555-\tmem_hotplug_done();\n--\nmm/memory_hotplug.c=1883=int offline_pages(unsigned long start_pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-1916-\t * Consequently, memory blocks with holes can never get onlined\nmm/memory_hotplug.c:1917:\t * via the hotplug path - online_pages() - as hotplugged memory has\nmm/memory_hotplug.c-1918-\t * no holes. This way, we don't have to worry about memory holes,\n--\nmm/mm_init.c=1523=void __ref free_area_init_core_hotplug(struct pglist_data *pgdat)\n--\nmm/mm_init.c-1554-\t * clear all zones' present_pages and managed_pages because they will\nmm/mm_init.c:1555:\t * be updated in online_pages() and offline_pages().\nmm/mm_init.c-1556-\t */\n"
}

gemini-3.1-pro-preview

null

null

							input: 11735
							output: 25
							thoughts: 31
						

Okay, here's my take on those thoughts, framed as my own:

**Considering Static Content & Exported Data**

Right, so I'm looking at how we're handling the presentation of our data. I'm focusing on the exported, or non-static, components represented by `online_pages` and `offline_pages`. I need to ensure everything's properly accounted for, and that the export process is robust. Since both `online_pages` and `offline_pages` are non-static and probably contain useful information, I should check on the `offline_pages` component as well. Let's make sure it’s handled just as carefully as the online component.

{
  "Expression": "offline_pages",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/memory_hotplug.c=528=void remove_pfn_range_from_zone(struct zone *zone,\n--\nmm/memory_hotplug.c-567- * sure that pages are marked reserved and zones are adjust properly by\nmm/memory_hotplug.c:568: * calling offline_pages().\nmm/memory_hotplug.c-569- */\n--\nmm/memory_hotplug.c=1871=static int count_system_ram_pages_cb(unsigned long start_pfn,\n--\nmm/memory_hotplug.c-1882- */\nmm/memory_hotplug.c:1883:int offline_pages(unsigned long start_pfn, unsigned long nr_pages,\nmm/memory_hotplug.c-1884-\t\t\tstruct zone *zone, struct memory_group *group)\n--\nmm/mm_init.c=1523=void __ref free_area_init_core_hotplug(struct pglist_data *pgdat)\n--\nmm/mm_init.c-1554-\t * clear all zones' present_pages and managed_pages because they will\nmm/mm_init.c:1555:\t * be updated in online_pages() and offline_pages().\nmm/mm_init.c-1556-\t */\n"
}

gemini-3.1-pro-preview

null

null

							input: 12275
							output: 26
							thoughts: 48
						

Okay, here's my take on those code candidates for fuzzing:

**My Fuzzing Target Brainstorm**

Right, let's see. Thinking about fuzzing this system, `online_pages` and `offline_pages` look like prime real estate for attack. These are the obvious entry points where data interaction is likely. Beyond those, I'm also eyeing methods like `__add_pages` and `__remove_pages`. Those internal functions could be susceptible to buffer overflows or unexpected input scenarios. Let's start by digging into `__add_pages` first; that seems like a good place to begin my analysis.

{
  "Expression": "__add_pages",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/memory_hotplug.c=379=EXPORT_SYMBOL_GPL(pfn_to_online_page);\nmm/memory_hotplug.c-380-\nmm/memory_hotplug.c:381:int __add_pages(int nid, unsigned long pfn, unsigned long nr_pages,\nmm/memory_hotplug.c-382-\t\tstruct mhp_params *params)\n"
}

gemini-3.1-pro-preview

null

null

							input: 12597
							output: 26
							thoughts: 20
						

Here's my thought process, as it stands:

**Checking the Page Management Functions**

Okay, so `__add_pages` is explicitly exported, which is good. That confirms its intended use and accessibility. Now, I need to verify its counterpart. Let's move on to checking the availability and functionality of `__remove_pages`. I need to ensure the system is complete and symmetric in its page manipulation capabilities. This is important for system reliability and predictable behavior. Let's see if `__remove_pages` is also exported and how it interacts with the rest of the module's architecture.

{
  "Expression": "__remove_pages",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/memory_hotplug.c=528=void remove_pfn_range_from_zone(struct zone *zone,\n--\nmm/memory_hotplug.c-558-/**\nmm/memory_hotplug.c:559: * __remove_pages() - remove sections of pages\nmm/memory_hotplug.c-560- * @pfn: starting pageframe (must be aligned to start of a section)\n--\nmm/memory_hotplug.c-569- */\nmm/memory_hotplug.c:570:void __remove_pages(unsigned long pfn, unsigned long nr_pages,\nmm/memory_hotplug.c-571-\t\t    struct vmem_altmap *altmap, struct dev_pagemap *pgmap)\n--\nmm/memremap.c=86=static void pageunmap_range(struct dev_pagemap *pgmap, int range_id)\n--\nmm/memremap.c-98-\tif (pgmap-\u003etype == MEMORY_DEVICE_PRIVATE) {\nmm/memremap.c:99:\t\t__remove_pages(PHYS_PFN(range-\u003estart),\nmm/memremap.c-100-\t\t\t       PHYS_PFN(range_len(range)), NULL, pgmap);\n"
}

gemini-3.1-pro-preview

null

null

							input: 13096
							output: 32
							thoughts: 38
						

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating Memory Management Operations**

Right, so `__remove_pages` is explicitly exported. That's interesting. I know that function, and it's key for a specific type of memory reclamation. But now I'm thinking about related operations… what about `move_pfn_range_to_zone` and `remove_pfn_range_from_zone`? They're clearly intended for manipulating page frame numbers (PFNs) and their allocation status within different memory zones. Are those exported as well? I can see a few use-cases for that, and it would really open up some possibilities. I need to check the export tables. Are they intended for use in some higher-level memory management functionality? Are they only intended for internal usage within the kernel, or are they potentially used by some drivers too? I want to determine their availability. It seems their exposure dictates a lot here.

{
  "Expression": "move_pfn_range_to_zone",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/memory_hotplug.c=711=static inline void section_taint_zone_device(unsigned long pfn)\n--\nmm/memory_hotplug.c-724- */\nmm/memory_hotplug.c:725:void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,\nmm/memory_hotplug.c-726-\t\t\t\t  unsigned long nr_pages,\n--\nmm/memory_hotplug.c=1064=int mhp_init_memmap_on_memory(unsigned long pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-1073-\nmm/memory_hotplug.c:1074:\tmove_pfn_range_to_zone(zone, pfn, nr_pages, NULL, MIGRATE_UNMOVABLE,\nmm/memory_hotplug.c-1075-\t\t\t       false);\n--\nmm/memory_hotplug.c=1118=int online_pages(unsigned long pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-1145-\t/* associate pfn range with the zone */\nmm/memory_hotplug.c:1146:\tmove_pfn_range_to_zone(zone, pfn, nr_pages, NULL, MIGRATE_MOVABLE,\nmm/memory_hotplug.c-1147-\t\t\t       true);\n--\nmm/memory_hotplug.c=2166=void try_offline_node(int nid)\n--\nmm/memory_hotplug.c-2171-\t * If the node still spans pages (especially ZONE_DEVICE), don't\nmm/memory_hotplug.c:2172:\t * offline it. A node spans memory after move_pfn_range_to_zone(),\nmm/memory_hotplug.c-2173-\t * e.g., after the memory block was onlined.\n--\nmm/memremap.c=144=static int pagemap_range(struct dev_pagemap *pgmap, struct mhp_params *params,\n--\nmm/memremap.c-228-\t\tzone = \u0026NODE_DATA(nid)-\u003enode_zones[ZONE_DEVICE];\nmm/memremap.c:229:\t\tmove_pfn_range_to_zone(zone, PHYS_PFN(range-\u003estart),\nmm/memremap.c-230-\t\t\t\tPHYS_PFN(range_len(range)), params-\u003ealtmap,\n"
}

gemini-3.1-pro-preview

null

null

							input: 14008
							output: 32
							thoughts: 40
						

Here's my summary, as the thought process unfolds:

**Examining PFN Range Management**

Okay, so `move_pfn_range_to_zone` isn't a symbol available for use outside the kernel module. That's a little unusual, but not necessarily a showstopper. What I *really* need to understand is how memory ranges are being managed at the zone level, which is why this came to mind in the first place, and why I wanted to study this function call, now unavailable to me.

Since `move_pfn_range_to_zone` is inaccessible, let's pivot and look at its potential counterpart function. The logical next place to dig is `remove_pfn_range_from_zone`. It's likely that a paired function like this exists, and understanding the reverse operation will provide critical context. Let's see if this one is exposed, and what we can learn about its implementation. This could illuminate the larger design.

{
  "Expression": "remove_pfn_range_from_zone",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/memory_hotplug.c=500=static void update_pgdat_span(struct pglist_data *pgdat)\n--\nmm/memory_hotplug.c-527-\nmm/memory_hotplug.c:528:void remove_pfn_range_from_zone(struct zone *zone,\nmm/memory_hotplug.c-529-\t\t\t\t      unsigned long start_pfn,\n--\nmm/memory_hotplug.c=1095=void mhp_deinit_memmap_on_memory(unsigned long pfn, unsigned long nr_pages)\n--\nmm/memory_hotplug.c-1110-\t */\nmm/memory_hotplug.c:1111:\tremove_pfn_range_from_zone(page_zone(pfn_to_page(pfn)), pfn, nr_pages);\nmm/memory_hotplug.c-1112-\tkasan_remove_zero_shadow(__va(PFN_PHYS(pfn)), PFN_PHYS(nr_pages));\n--\nmm/memory_hotplug.c=1118=int online_pages(unsigned long pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-1228-\t\tnode_notify(NODE_CANCEL_ADDING_FIRST_MEMORY, \u0026node_arg);\nmm/memory_hotplug.c:1229:\tremove_pfn_range_from_zone(zone, pfn, nr_pages);\nmm/memory_hotplug.c-1230-\treturn ret;\n--\nmm/memory_hotplug.c=1883=int offline_pages(unsigned long start_pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-2080-\tmemory_notify(MEM_OFFLINE, \u0026mem_arg);\nmm/memory_hotplug.c:2081:\tremove_pfn_range_from_zone(zone, start_pfn, nr_pages);\nmm/memory_hotplug.c-2082-\treturn 0;\n--\nmm/memremap.c=86=static void pageunmap_range(struct dev_pagemap *pgmap, int range_id)\n--\nmm/memremap.c-95-\tmem_hotplug_begin();\nmm/memremap.c:96:\tremove_pfn_range_from_zone(page_zone(first_page), PHYS_PFN(range-\u003estart),\nmm/memremap.c-97-\t\t\t\t   PHYS_PFN(range_len(range)));\n"
}

gemini-3.1-pro-preview

null

null

							input: 14930
							output: 29
							thoughts: 57
						

Okay, here's my take on those code targets, presented as my own mental processing:

**Analyzing Potential Hotplug Optimization Points**

Right, so I'm looking at improving memory hotplug handling. Immediately, `move_pfn_range_to_zone` and `remove_pfn_range_from_zone` are standing out as prime candidates. They're clearly at the core of manipulating memory regions, and any efficiency gains there would be significant. I'm also adding `online_pages` and `offline_pages` to the mix – these are likely involved in the state transitions and resource management during the hotplug process. I need to understand how these routines interact and where the bottlenecks might lie.

Now, a key factor here is going to be the kernel configuration. I need to quickly check the status of `CONFIG_MEMORY_HOTPLUG`. Is it enabled? That’s my starting point. The presence or absence of that config option will dictate the overall architecture I'm working with and the subsequent optimization strategies I'll need to use. I need to be aware of the context and any conditional compilation that could be impacting these functions.

{
  "Expression": "config MEMORY_HOTPLUG",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/Kconfig=519=config ARCH_ENABLE_MEMORY_HOTPLUG\n--\nmm/Kconfig-522-# eventually, we can have this option just 'select SPARSEMEM'\nmm/Kconfig:523:menuconfig MEMORY_HOTPLUG\nmm/Kconfig-524-\tbool \"Memory hotplug\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 15352
							output: 32
							thoughts: 20
						

Here's a summary of my thought process:

**Diving into the Kernel Configuration for Memory Hotplug**

Okay, so I need to figure out the dependencies related to `MEMORY_HOTPLUG`. My immediate approach is to head straight to the `mm/Kconfig` file. That's the logical place to start digging into memory management configuration options within the kernel. I'm expecting to find conditional logic and dependencies defined there – specifically, which other configuration symbols need to be enabled before `MEMORY_HOTPLUG` can be selected. This is the critical first step in understanding the broader implications of this feature and how it interacts with other kernel subsystems. I'll be looking for relationships with NUMA, ACPI, or anything that touches on dynamic memory allocation and deallocation. Let's see what `mm/Kconfig` reveals...

{
  "File": "mm/Kconfig",
  "FirstLine": 520,
  "LineCount": 20
}

{
  "Contents": " 520:\t\tbool\n 521:\t\n 522:\t# eventually, we can have this option just 'select SPARSEMEM'\n 523:\tmenuconfig MEMORY_HOTPLUG\n 524:\t\tbool \"Memory hotplug\"\n 525:\t\tselect MEMORY_ISOLATION\n 526:\t\tdepends on SPARSEMEM_VMEMMAP\n 527:\t\tdepends on ARCH_ENABLE_MEMORY_HOTPLUG\n 528:\t\tdepends on 64BIT\n 529:\t\tselect NUMA_KEEP_MEMINFO if NUMA\n 530:\t\n 531:\tif MEMORY_HOTPLUG\n 532:\t\n 533:\tchoice\n 534:\t\tprompt \"Memory Hotplug Default Online Type\"\n 535:\t\tdefault MHP_DEFAULT_ONLINE_TYPE_OFFLINE\n 536:\t\thelp\n 537:\t\t  Default memory type for hotplugged memory.\n 538:\t\n 539:\t\t  This option sets the default policy setting for memory hotplug\n"
}

gemini-3.1-pro-preview

null

null

							input: 15859
							output: 29
							thoughts: 318
						

**Analyzing Memory Hotplug and Initialization Changes**

Okay, so I'm looking at this configuration related to `MEMORY_HOTPLUG`, and I should probably also enable `SPARSEMEM_VMEMMAP` since it's a dependency. Actually, isn't `SPARSEMEM_VMEMMAP` usually enabled anyway? Let me double-check.

Right, I need to understand what's changed in `mm/mm_init.c`. Ah, I see `unavailable_pfn_is_online` is used in `init_unavailable_range`. And that function is called from `memmap_init_zone_range`, which in turn gets called from `free_area_init_node` during boot. Okay, so this code is definitely executed during boot if there are unavailable memory ranges, which is important to know.

This patch is definitely making some functional changes to how memory hotplug works, alongside how memory is initialized. Replacing the old `set_zone_contiguous` call with a simpler check using `zone->spanned_pages == zone->pages_with_online_memmap` to determine memory state is definitely an interesting optimization. This is something worth throwing a fuzzer at.

Let's list the key symbols of interest. I'm focusing on: `online_pages`, `offline_pages`, `move_pfn_range_to_zone`, `remove_pfn_range_from_zone`, `__add_pages`, and `__remove_pages`.

I should check if `online_pages` and `offline_pages` are exported. Is `online_pages` exported? No, but I know `generic_online_page` is exported. Let me double check that!

no matches

{
  "Expression": "EXPORT_SYMBOL.*online_pages",
  "PathPrefix": "mm/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 16590
							output: 29
							thoughts: 9
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**Initial Assessment: Navigating the Landscape**

Alright, before diving into the core problem, I'm going to take a moment to survey the relevant codebase. My immediate thought is to check `offline_pages`. Given the context – whatever the user's issue might be – this is a logical first step. Offline functionality is a common source of unexpected behavior, especially when dealing with data persistence, caching, or interactions that *should* be available when disconnected. It's a foundational module and usually reveals foundational assumptions about the system's behavior when offline. I'm assuming it handles the mechanics of providing, syncing, storing and removing offline content. So, I need to understand how the system's architecture and assumptions are implemented there, so, before even considering the problem, understanding this is the logical next step.

no matches

{
  "Expression": "EXPORT_SYMBOL.*offline_pages",
  "PathPrefix": "mm/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 16836
							output: 30
							thoughts: 29
						

Okay, here's my interpretation of those thoughts, summarized from my perspective as a seasoned expert:

**Internal Audit & Code Review**

Right, so these functions aren't explicitly exported, which is interesting. That usually means they're intended for internal use within the module or library, not for direct external interaction. But, the fact that they're global functions raises a flag. Even without explicit exporting, their global scope means they're potentially accessible from anywhere within the program's context. I need to understand their behavior and impact, so let's dig into those function names – `__add_pages` and `__remove_pages`. I'll want to see how they're *actually* used, and in what ways. Specifically, I'll be looking for any signs of unsafe memory manipulation, unexpected side effects, or potential for unintended access or modification of data. A deep dive is in order.

no matches

{
  "Expression": "EXPORT_SYMBOL.*__add_pages",
  "PathPrefix": "mm/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 17101
							output: 29
							thoughts: 40
						

Okay, here's my interpretation of that thought process, assuming I'm deep in the kernel code:

**Checking That Page Addition**

Hmm, hold on a second. I swear I saw that `EXPORT_SYMBOL_GPL(pfn_to_online_page)` declaration *before* that `__add_pages` function call. Something feels off about the order, or perhaps the intended use. Let me just quickly go back and thoroughly re-examine the implementation of `__add_pages`. I need to ensure I'm understanding the relationship between page allocation and symbol exports correctly, and I want to make sure I haven't missed a critical dependency or usage pattern. It's that nagging feeling... gotta make sure I didn't miss something fundamental in the way these page structures are being manipulated. It could be important!

no matches

{
  "Expression": "EXPORT_SYMBOL.*add_pages",
  "PathPrefix": "mm/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 17359
							output: 31
							thoughts: 10
						

Okay, here's the summary, rendered as if I'm the one thinking it:

**Initial Assessment: Function Availability**

Ah, the function `add_pages` is actually exported. This is good, good! It means it's available for me to directly call and use within my own code or in other modules. This opens up a lot of possibilities for modularity and integration. I can now start to think about how I can leverage this function in my current project, perhaps to automate a repetitive task, enhance an existing process, or even build a small utility around it. The implications for workflow optimization are certainly there. I'll need to look at the function's documentation to confirm parameters and return value but this first observation is promising.

{
  "Expression": "add_pages",
  "PathPrefix": "mm/memory_hotplug.c"
}

{
  "Output": "mm/memory_hotplug.c=379=EXPORT_SYMBOL_GPL(pfn_to_online_page);\nmm/memory_hotplug.c-380-\nmm/memory_hotplug.c:381:int __add_pages(int nid, unsigned long pfn, unsigned long nr_pages,\nmm/memory_hotplug.c-382-\t\tstruct mhp_params *params)\n"
}

gemini-3.1-pro-preview

null

null

							input: 17669
							output: 35
							thoughts: 25
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Investigating a Module's Page Addition Functionality**

Okay, hold on a second. I was under the impression that the internal `__add_pages` method was the one responsible for the core page addition logic within this module. But, wait... I just realized I can't directly access it. That's odd. It's not exported. Could the public-facing function be `add_pages` then? I need to quickly verify if *that* one is exported, and if so, understand how the public function interfaces with any internal functionality. Let's dig into the code and confirm which function is actually exposed in the public interface.

no matches

{
  "Expression": "EXPORT_SYMBOL.*add_pages",
  "PathPrefix": "mm/memory_hotplug.c"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 17898
							output: 35
							thoughts: 10
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**A Quick Jolt of Realization**

Wait a second... `add_memory` is *exported*? That's not what I was expecting at all. I was under the impression that this was going to be an internal utility function, perhaps part of a private API within the module. My initial assumptions were clearly off-base. That export status dramatically shifts my mental model of how this component is intended to be used and, more importantly, how it interacts with other parts of the system. I need to immediately reconsider my previous understanding of its scope, potential side effects, and any public facing guarantees that might come with its external accessibility. This warrants a more in-depth look at the module's documentation and external API contracts to fully understand the implications.

{
  "Expression": "EXPORT_SYMBOL.*add_memory",
  "PathPrefix": "mm/memory_hotplug.c"
}

{
  "Output": "mm/memory_hotplug.c=1598=int add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags)\n--\nmm/memory_hotplug.c-1607-}\nmm/memory_hotplug.c:1608:EXPORT_SYMBOL_GPL(add_memory);\nmm/memory_hotplug.c-1609-\n--\nmm/memory_hotplug.c=1631=int add_memory_driver_managed(int nid, u64 start, u64 size,\n--\nmm/memory_hotplug.c-1657-}\nmm/memory_hotplug.c:1658:EXPORT_SYMBOL_GPL(add_memory_driver_managed);\nmm/memory_hotplug.c-1659-\n"
}

gemini-3.1-pro-preview

null

null

							input: 18330
							output: 39
							thoughts: 260
						

**Fuzzing Memory Management Functions**

Okay, so `add_memory` *is* exported, but that doesn't really matter for fuzzing with syzkaller. We can reach non-exported functions if they're accessible through syscalls or sysfs, which is great. I was thinking that syzkaller could definitely fuzz `online_pages` through sysfs, which is interesting. However, to really hone in on specific areas, let's look at more specific options to focus on: `online_pages`, `offline_pages`, `move_pfn_range_to_zone`, and `remove_pfn_range_from_zone`.

Let's do a quick check to see if `online_pages` is a viable focus symbol, and it looks like it isn't static. Alright, let's keep going and check the others. `offline_pages` also isn't static. How about `move_pfn_range_to_zone`? Nope, not static. And `remove_pfn_range_from_zone`? No, still not static.

Now, on the other hand, `memory_block_online` and `memory_block_offline` are static. So we're not going to be using them as focus symbols, since they wouldn't be accessible to syzkaller directly.

Let's pivot and check `mhp_init_memmap_on_memory` and `mhp_deinit_memmap_on_memory`.

{
  "Expression": "mhp_init_memmap_on_memory",
  "PathPrefix": "mm/memory_hotplug.c"
}

{
  "Output": "mm/memory_hotplug.c=1042=void adjust_present_page_count(struct page *page, struct memory_group *group,\n--\nmm/memory_hotplug.c-1063-\nmm/memory_hotplug.c:1064:int mhp_init_memmap_on_memory(unsigned long pfn, unsigned long nr_pages,\nmm/memory_hotplug.c-1065-\t\t\t      struct zone *zone)\n"
}

gemini-3.1-pro-preview

null

null

							input: 19079
							output: 33
							thoughts: 17
						

Okay, here's my attempt at summarizing those thoughts from a first-person, expert perspective, aiming for a fulsome rendering:

**My Fluid Framework: Constant Evolution**

Alright, so I'm thinking... this isn't a simple, static situation. Everything I deal with in this area is dynamic, constantly shifting. I need to keep that in mind as I approach this. The underlying principles might remain, but the application and the specifics are always evolving, and I need to be ready to adapt my mental model and my approach.

Specifically, I need to zoom in on a particular aspect. Let's see... *shrink\_zone\_span*. That's the key variable at play here, and its state is likely critical. I should immediately check how that's behaving. Let me focus on that and see what that's telling me.

{
  "Expression": "shrink_zone_span",
  "PathPrefix": "mm/memory_hotplug.c"
}

{
  "Output": "mm/memory_hotplug.c=451=static unsigned long find_biggest_section_pfn(struct zone *zone,\n--\nmm/memory_hotplug.c-460-\nmm/memory_hotplug.c:461:static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,\nmm/memory_hotplug.c-462-\t\t\t     unsigned long end_pfn)\n--\nmm/memory_hotplug.c=528=void remove_pfn_range_from_zone(struct zone *zone,\n--\nmm/memory_hotplug.c-553-\nmm/memory_hotplug.c:554:\tshrink_zone_span(zone, start_pfn, start_pfn + nr_pages);\nmm/memory_hotplug.c-555-\tupdate_pgdat_span(pgdat);\n"
}

gemini-3.1-pro-preview

null

null

							input: 19534
							output: 28
							thoughts: 120
						

**Analyzing the Memory Management Code**

Okay, this feels pretty static, not a lot of dynamic interplay happening, which is helpful for focused analysis. I need to zero in on the key symbols, and the ones that jump out as critical are: `online_pages`, `offline_pages`, the zone manipulation functions `move_pfn_range_to_zone` and `remove_pfn_range_from_zone`, and the page addition/removal primitives `__add_pages` and `__remove_pages`. These seem to represent the core operations in play here.

Now, I also see this `MEMORY_HOTPLUG` configuration variable floating around. Hmm, that's potentially important. Let me quickly verify my assumptions – it's crucial to understand the context. Yes, `mm/memory_hotplug.c` is definitely compiled when `CONFIG_MEMORY_HOTPLUG` is set. So, this code block is directly related to hotplugging, as expected. Good, confirmation is key. This gives me a framework for looking at how memory is handled on-the-fly.

{
  "Expression": "memory_hotplug.o",
  "PathPrefix": "mm/"
}

{
  "Output": "mm/Makefile=62=page-alloc-$(CONFIG_SHUFFLE_PAGE_ALLOCATOR) += shuffle.o\n--\nmm/Makefile-64-# Give 'memory_hotplug' its own module-parameter namespace\nmm/Makefile:65:memory-hotplug-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o\nmm/Makefile-66-\n--\nmm/memory_hotplug.c=152=static int get_online_policy(char *buffer, const struct kernel_param *kp)\n--\nmm/memory_hotplug.c-157-/*\nmm/memory_hotplug.c:158: * memory_hotplug.online_policy: configure online behavior when onlining without\nmm/memory_hotplug.c-159- * specifying a zone (MMOP_ONLINE)\n"
}

gemini-3.1-pro-preview

null

null

							input: 20122
							output: 27
							thoughts: 57
						

**Makefile Confusion**

Okay, hold on a second. I'm looking at `mm/Makefile` and something's not quite clicking. I see `memory-hotplug-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o`, which seems standard enough. But then, *right after that*, I'm seeing `obj-y += memory-hotplug.o`. That's... redundant, right? Surely, the conditional assignment should handle things. I need to understand why both are present. Is there some subtle interaction with `CONFIG_MEMORY_HOTPLUG` that I'm missing? Or is this a legacy thing, maybe some optimization or a specific build scenario I'm not immediately grasping? Time to dive back into `mm/Makefile` and figure out what's going on here.

{
  "Expression": "memory-hotplug",
  "PathPrefix": "mm/Makefile"
}

{
  "Output": "mm/Makefile=62=page-alloc-$(CONFIG_SHUFFLE_PAGE_ALLOCATOR) += shuffle.o\n--\nmm/Makefile-64-# Give 'memory_hotplug' its own module-parameter namespace\nmm/Makefile:65:memory-hotplug-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o\nmm/Makefile-66-\n--\nmm/Makefile=70=obj-y += memblock.o\nmm/Makefile:71:obj-y += $(memory-hotplug-y)\nmm/Makefile-72-obj-y += slub.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 20534
							output: 31
							thoughts: 58
						

**Kernel Configuration Conundrum**

Alright, so `CONFIG_MEMORY_HOTPLUG`, that feels right, that's what I'm going with. Double-checking isn't a bad idea, though. Hmm, is there anything else I need to factor in here? Ah yes, `SPARSEMEM_VMEMMAP`. That's a dependency of `MEMORY_HOTPLUG`, isn't it? Let me just make sure I'm not missing any other relevant configurations. Back to `mm/Kconfig` for another quick scan, just to be thorough. Gotta cover all the bases!

{
  "Expression": "config MEMORY_HOTPLUG",
  "PathPrefix": "mm/Kconfig"
}

{
  "Output": "mm/Kconfig=519=config ARCH_ENABLE_MEMORY_HOTPLUG\n--\nmm/Kconfig-522-# eventually, we can have this option just 'select SPARSEMEM'\nmm/Kconfig:523:menuconfig MEMORY_HOTPLUG\nmm/Kconfig-524-\tbool \"Memory hotplug\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 20846
							output: 32
							thoughts: 130
						

**Checking SPARSEMEM_VMEMMAP and Memory Hotplug**

Okay, let's see about this `SPARSEMEM_VMEMMAP` option. My initial thought is to make sure it's enabled, given that `MEMORY_HOTPLUG` depends on it. The Kbuild system should theoretically handle this dependency correctly; if I enable `MEMORY_HOTPLUG`, Kbuild *should* also ensure `SPARSEMEM_VMEMMAP` is enabled. But, as an expert, I know that safe is better than sorry. I should probably explicitly specify `SPARSEMEM_VMEMMAP` alongside `MEMORY_HOTPLUG` just to be certain. Hang on... isn't `SPARSEMEM_VMEMMAP` pretty much always enabled by default on x86_64 architectures? That rings a bell. Okay, I need to confirm this. I'll take a look at the `mm/Kconfig` file to double-check the default behavior of `SPARSEMEM_VMEMMAP`. Better to verify this assumption than to proceed based on a potentially incorrect recollection.

{
  "Expression": "config SPARSEMEM_VMEMMAP",
  "PathPrefix": "mm/Kconfig"
}

{
  "Output": "mm/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\n--\nmm/Kconfig-465-\nmm/Kconfig:466:config SPARSEMEM_VMEMMAP_PREINIT\nmm/Kconfig-467-\tbool\n"
}

gemini-3.1-pro-preview

null

null

							input: 21406
							output: 34
							thoughts: 31
						

Okay, here's my interpretation of those thoughts, presented as my own mental process, given my expertise:

**Checking the Validity of a Configuration Setting**

Right, `def_bool y`. This is straightforward. No need for further parsing or deeper analysis here; a `def_bool` with a value of 'y' indicates that a configuration option is definitely *enabled*. That's the expected and desired state. It's a clean and clear affirmation of its status.

Now, let's just quickly double-check another related variable to make sure nothing has changed unexpectedly, or introduced a conflict. Let's see... I'll check `ARCH_ENABLE_MEMORY_HOTPLUG`. I just want to ensure that memory hotplug is enabled in this context.

{
  "Expression": "config ARCH_ENABLE_MEMORY_HOTPLUG",
  "PathPrefix": "mm/Kconfig"
}

{
  "Output": "mm/Kconfig=516=config HAVE_BOOTMEM_INFO_NODE\n--\nmm/Kconfig-518-\nmm/Kconfig:519:config ARCH_ENABLE_MEMORY_HOTPLUG\nmm/Kconfig-520-\tbool\n"
}

gemini-3.1-pro-preview

null

null

							input: 21708
							output: 35
							thoughts: 437
						

**Analyzing the Memory Hotplug Changes**

Okay, so this patch is driven by architectural choices, which means `MEMORY_HOTPLUG` is the key configuration to watch. Let's break down the changes. It looks like they've added a new field, `pages_with_online_memmap`, to the `struct zone`. The point is to make the `zone_is_contiguous()` check much faster – O(1) now by comparing `spanned_pages` and `pages_with_online_memmap`, instead of the old O(N) `set_zone_contiguous()` which was iterating over pageblocks. A pretty significant performance win, if it works as advertised.

Essentially, we're talking about fundamental changes to core memory management and how memory hotplug works. That makes this patch a great candidate for fuzzing, since the reach is so broad.

Now, let's nail down the key symbols. We've got:

*   `online_pages`
*   `offline_pages`
*   `move_pfn_range_to_zone`
*   `remove_pfn_range_from_zone`
*   `__add_pages`
*   `__remove_pages`

Checking them, it's all good. `online_pages` is called during memory onlining, `offline_pages` during offlining. The other four cover adding and removing memory ranges, which is exactly what we're interested in.

Alright, what else is in here? Let's quickly check other functions, just to be sure. Looks like `init_unavailable_range` and `memmap_init_zone_range` are static and only called at boot, so we can ignore them. `adjust_present_page_count` is not static, so let's investigate it.

{
  "Expression": "adjust_present_page_count",
  "PathPrefix": "mm/memory_hotplug.c"
}

{
  "Output": "mm/memory_hotplug.c=1022=struct zone *zone_for_pfn_range(enum mmop online_type, int nid,\n--\nmm/memory_hotplug.c-1041- */\nmm/memory_hotplug.c:1042:void adjust_present_page_count(struct page *page, struct memory_group *group,\nmm/memory_hotplug.c-1043-\t\t\t       long nr_pages)\n--\nmm/memory_hotplug.c=1118=int online_pages(unsigned long pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-1181-\tonline_pages_range(pfn, nr_pages);\nmm/memory_hotplug.c:1182:\tadjust_present_page_count(pfn_to_page(pfn), group, nr_pages);\nmm/memory_hotplug.c-1183-\n--\nmm/memory_hotplug.c=1883=int offline_pages(unsigned long start_pfn, unsigned long nr_pages,\n--\nmm/memory_hotplug.c-2043-\tadjust_managed_page_count(pfn_to_page(start_pfn), -managed_pages);\nmm/memory_hotplug.c:2044:\tadjust_present_page_count(pfn_to_page(start_pfn), group, -nr_pages);\nmm/memory_hotplug.c-2045-\n"
}

gemini-3.1-pro-preview

null

null

							input: 22954
							output: 34
							thoughts: 40
						

Okay, here's my interpretation of those calls, putting myself in the role of thinking through this code:

**Understanding the Origins of This Function's Calls**

Alright, let's break this down. It seems this function is quite versatile, being utilized in a few key areas of the system. I see calls originating from both the `online_pages` and `offline_pages` subsystems. That's immediately interesting; it suggests a role in page management, perhaps in transitioning pages between online and offline states, or some kind of page allocation/deallocation process related to these two page lists. The fact that it's handling both online and offline pages indicates it's central to the memory management strategy.

Now, the plot thickens a bit. I also see a call from within `drivers/base/memory.c`, specifically from a function named `memory_block_offline`. This is potentially crucial. "drivers" implies this has something to do with interaction with the hardware. `memory_block_offline`... okay, that almost certainly suggests this function is involved when a memory block is being taken offline. That's a very specific context, likely related to NUMA node management, memory hotplugging, or perhaps even handling memory failures. It's working at a lower level now, managing pages as part of a larger unit of memory. I'll need to dig into the surrounding code to determine *how* it's involved, but that alone suggests it's more than just a simple page manipulator, but critical to the memory state, and how the OS interacts with the hardware.

{
  "Expression": "adjust_present_page_count",
  "PathPrefix": "drivers/base/memory.c"
}

{
  "Output": "drivers/base/memory.c=224=static int memory_block_online(struct memory_block *mem)\n--\ndrivers/base/memory.c-268-\tif (nr_vmemmap_pages)\ndrivers/base/memory.c:269:\t\tadjust_present_page_count(pfn_to_page(start_pfn), mem-\u003egroup,\ndrivers/base/memory.c-270-\t\t\t\t\t  nr_vmemmap_pages);\n--\ndrivers/base/memory.c=282=static int memory_block_offline(struct memory_block *mem)\n--\ndrivers/base/memory.c-301-\tif (nr_vmemmap_pages)\ndrivers/base/memory.c:302:\t\tadjust_present_page_count(pfn_to_page(start_pfn), mem-\u003egroup,\ndrivers/base/memory.c-303-\t\t\t\t\t  -nr_vmemmap_pages);\n--\ndrivers/base/memory.c-309-\t\tif (nr_vmemmap_pages)\ndrivers/base/memory.c:310:\t\t\tadjust_present_page_count(pfn_to_page(start_pfn),\ndrivers/base/memory.c-311-\t\t\t\t\t\t  mem-\u003egroup, nr_vmemmap_pages);\n"
}

gemini-3.1-pro-preview

null

null

							input: 23693
							output: 38
							thoughts: 49
						

Okay, here's my take on those thoughts, framed as my own:

**Analyzing Memory Management Targets**

Right, so `adjust_present_page_count` looks like another potential point of interest. I need to keep that in mind as a likely target for investigation. The memory mapping initialization and de-initialization routines, specifically `mhp_init_memmap_on_memory` and `mhp_deinit_memmap_on_memory`, are also crucial functions to examine in this context. These functions will likely contain key logic related to managing and manipulating the memory map. They have to be considered as potential focal points for whatever I'm troubleshooting.

{
  "Expression": "mhp_init_memmap_on_memory",
  "PathPrefix": "drivers/base/memory.c"
}

{
  "Output": "drivers/base/memory.c=224=static int memory_block_online(struct memory_block *mem)\n--\ndrivers/base/memory.c-250-\tif (nr_vmemmap_pages) {\ndrivers/base/memory.c:251:\t\tret = mhp_init_memmap_on_memory(start_pfn, nr_vmemmap_pages, zone);\ndrivers/base/memory.c-252-\t\tif (ret)\n"
}

gemini-3.1-pro-preview

null

null

							input: 24049
							output: 184
							thoughts: 96
						

Here's my analysis of the situation:

**Reflecting on Memory Management Operations**

Okay, so I'm observing a set of functions that deal with memory block management, specifically the online and offline procedures. The key functions, or rather, the symbols that define their core operations, seem to be: `online_pages`, `offline_pages`, `move_pfn_range_to_zone`, `remove_pfn_range_from_zone`, `__add_pages`, `__remove_pages`, and `adjust_present_page_count`.

These symbols point to the fundamental building blocks of how the system handles the allocation, deallocation, and movement of physical page frames (PFNs) between zones, and the accounting associated with them. Now that I have a clear understanding of the involved function symbols and their context, I'm ready to assign results.

{
  "EnableConfigs": [
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "online_pages",
    "offline_pages",
    "move_pfn_range_to_zone",
    "remove_pfn_range_from_zone",
    "__add_pages",
    "__remove_pages",
    "adjust_present_page_count"
  ],
  "Reasoning": "The patch introduces a functional change in how contiguous zones are tracked, replacing an O(N) pageblock iteration with an O(1) check using a new `pages_with_online_memmap` counter in `struct zone`. This counter is updated during memory hotplug and initialization. The changes affect core memory management and memory hotplug logic, which are reachable in virtualized environments and should be fuzzed.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "MEMORY_HOTPLUG"
  ],
  "FocusSymbols": [
    "online_pages",
    "offline_pages",
    "move_pfn_range_to_zone",
    "remove_pfn_range_from_zone",
    "__add_pages",
    "__remove_pages",
    "adjust_present_page_count"
  ],
  "Reasoning": "The patch introduces a functional change in how contiguous zones are tracked, replacing an O(N) pageblock iteration with an O(1) check using a new `pages_with_online_memmap` counter in `struct zone`. This counter is updated during memory hotplug and initialization. The changes affect core memory management and memory hotplug logic, which are reachable in virtualized environments and should be fuzzed.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch modifies memory hotplug and zone contiguous tracking logic by introducing `pages_with_online_memmap` to `struct zone` and updating how `zone_is_contiguous` is evaluated. These changes involve updating counters and boolean flags, and do not introduce new stack or heap allocations that could be left uninitialized. There are no structures copied to user space, so there is no risk of info-leaks. Any bugs introduced by these changes (e.g., incorrect contiguous zone evaluation) would likely result in out-of-bounds accesses, NULL pointer dereferences, or invalid page struct accesses, which are effectively caught by KASAN and standard kernel debugging tools. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

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.

For your convenience, here is the diff of the changes:
commit ed143ca6fafd3825686db2caf91180eb6d0bffb2
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 18 09:06:37 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst
index b76183545e5bf..ceea6c8b27cc1 100644
--- a/Documentation/mm/physical_memory.rst
+++ b/Documentation/mm/physical_memory.rst
@@ -483,6 +483,12 @@ General
   ``present_pages`` should use ``get_online_mems()`` to get a stable value. It
   is initialized by ``calculate_node_totalpages()``.
 
+``pages_with_online_memmap``
+  Pages within the zone that have an online memory map: present pages and
+  memory holes whose memory map has been initialized and
+  ``pfn_to_online_page()`` succeeds. See the comment for
+  ``pages_with_online_memmap`` in ``include/linux/mmzone.h`` for more details.
+
 ``present_early_pages``
   The present pages existing within the zone located on memory available since
   early boot, excluding hotplugged memory. Defined only when
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bcfe2d9f4adbd..97699be9a3578 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -246,6 +246,7 @@ static int memory_block_online(struct memory_block *mem)
 		nr_vmemmap_pages = mem->altmap->free;
 
 	mem_hotplug_begin();
+	clear_zone_contiguous(zone);
 	if (nr_vmemmap_pages) {
 		ret = mhp_init_memmap_on_memory(start_pfn, nr_vmemmap_pages, zone);
 		if (ret)
@@ -270,6 +271,7 @@ static int memory_block_online(struct memory_block *mem)
 
 	mem->zone = zone;
 out:
+	set_zone_contiguous(zone);
 	mem_hotplug_done();
 	return ret;
 }
@@ -295,6 +297,7 @@ static int memory_block_offline(struct memory_block *mem)
 		nr_vmemmap_pages = mem->altmap->free;
 
 	mem_hotplug_begin();
+	clear_zone_contiguous(mem->zone);
 	if (nr_vmemmap_pages)
 		adjust_present_page_count(pfn_to_page(start_pfn), mem->group,
 					  -nr_vmemmap_pages);
@@ -312,8 +315,10 @@ static int memory_block_offline(struct memory_block *mem)
 	if (nr_vmemmap_pages)
 		mhp_deinit_memmap_on_memory(start_pfn, nr_vmemmap_pages);
 
-	mem->zone = NULL;
 out:
+	set_zone_contiguous(mem->zone);
+	if (!ret)
+		mem->zone = NULL;
 	mem_hotplug_done();
 	return ret;
 }
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index ca27121871475..58f342de3bacb 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1032,6 +1032,21 @@ struct zone {
 	 * cma pages is present pages that are assigned for CMA use
 	 * (MIGRATE_CMA).
 	 *
+	 * pages_with_online_memmap tracks pages within the zone that have
+	 * an online memory map: present pages and memory holes whose
+	 * memory map has been initialized and pfn_to_online_page()
+	 * succeeds. When spanned_pages == pages_with_online_memmap,
+	 * pfn_to_page() can be performed without further checks on any
+	 * PFN within the zone span.
+	 *
+	 * Note: this counter may temporarily undercount when pages with an
+	 * online memory map exist outside the current zone span. This can
+	 * only happen during boot, when initializing the memory map of
+	 * pages that do not fall into any zone span. Growing the zone to
+	 * cover such pages and later shrinking it back may result in a
+	 * "too small" value. This is safe: it merely prevents detecting a
+	 * contiguous zone.
+	 *
 	 * So present_pages may be used by memory hotplug or memory power
 	 * management logic to figure out unmanaged pages by checking
 	 * (present_pages - managed_pages). And managed_pages should be used
@@ -1056,6 +1071,7 @@ struct zone {
 	atomic_long_t		managed_pages;
 	unsigned long		spanned_pages;
 	unsigned long		present_pages;
+	unsigned long		pages_with_online_memmap;
 #if defined(CONFIG_MEMORY_HOTPLUG)
 	unsigned long		present_early_pages;
 #endif
@@ -1681,6 +1697,38 @@ static inline bool zone_is_zone_device(const struct zone *zone)
 }
 #endif
 
+/**
+ * zone_is_contiguous - test whether a zone is contiguous
+ * @zone: the zone to test.
+ *
+ * In a contiguous zone, it is valid to call pfn_to_page() on any PFN in the
+ * spanned zone without requiring pfn_valid() or pfn_to_online_page() checks.
+ *
+ * Note that missing synchronization with memory offlining makes any PFN
+ * traversal prone to races.
+ *
+ * ZONE_DEVICE zones are always marked non-contiguous.
+ *
+ * Return: true if contiguous, otherwise false.
+ */
+static inline bool zone_is_contiguous(const struct zone *zone)
+{
+	return READ_ONCE(zone->contiguous);
+}
+
+static inline void set_zone_contiguous(struct zone *zone)
+{
+	if (zone_is_zone_device(zone))
+		return;
+	if (zone->spanned_pages == zone->pages_with_online_memmap)
+		WRITE_ONCE(zone->contiguous, true);
+}
+
+static inline void clear_zone_contiguous(struct zone *zone)
+{
+	WRITE_ONCE(zone->contiguous, false);
+}
+
 /*
  * Returns true if a zone has pages managed by the buddy allocator.
  * All the reclaim decisions have to use this function rather than
diff --git a/mm/internal.h b/mm/internal.h
index 181e79f1d6a20..f932b7577c92a 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -805,21 +805,15 @@ extern struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
 static inline struct page *pageblock_pfn_to_page(unsigned long start_pfn,
 				unsigned long end_pfn, struct zone *zone)
 {
-	if (zone->contiguous)
+	if (zone_is_contiguous(zone))
 		return pfn_to_page(start_pfn);
 
 	return __pageblock_pfn_to_page(start_pfn, end_pfn, zone);
 }
 
-void set_zone_contiguous(struct zone *zone);
 bool pfn_range_intersects_zones(int nid, unsigned long start_pfn,
 			   unsigned long nr_pages);
 
-static inline void clear_zone_contiguous(struct zone *zone)
-{
-	zone->contiguous = false;
-}
-
 extern int __isolate_free_page(struct page *page, unsigned int order);
 extern void __putback_isolated_page(struct page *page, unsigned int order,
 				    int mt);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 7ac19fab22632..8dbd50d88155a 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -422,49 +422,39 @@ int __add_pages(int nid, unsigned long pfn, unsigned long nr_pages,
 	return err;
 }
 
-/* find the smallest valid pfn in the range [start_pfn, end_pfn) */
-static unsigned long find_smallest_section_pfn(int nid, struct zone *zone,
-				     unsigned long start_pfn,
-				     unsigned long end_pfn)
+static bool subsection_overlaps_zone(unsigned long pfn, struct zone *zone)
 {
-	for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SUBSECTION) {
-		if (unlikely(!pfn_to_online_page(start_pfn)))
-			continue;
+	const unsigned long start_pfn = ALIGN_DOWN(pfn, PAGES_PER_SUBSECTION);
+	const unsigned long end_pfn = start_pfn + PAGES_PER_SUBSECTION - 1;
 
-		if (unlikely(pfn_to_nid(start_pfn) != nid))
-			continue;
+	/* All pages in a subsection are either online or offline. */
+	if (unlikely(!pfn_to_online_page(start_pfn)))
+		return false;
 
-		if (zone != page_zone(pfn_to_page(start_pfn)))
-			continue;
+	/* Checking start+end is sufficient. */
+	return zone == page_zone(pfn_to_page(start_pfn)) ||
+	       zone == page_zone(pfn_to_page(end_pfn));
+}
 
-		return start_pfn;
+/* find the smallest valid pfn in the range [start_pfn, end_pfn) */
+static unsigned long find_smallest_section_pfn(struct zone *zone,
+		unsigned long start_pfn, unsigned long end_pfn)
+{
+	for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SUBSECTION) {
+		if (subsection_overlaps_zone(start_pfn, zone))
+			return start_pfn;
 	}
-
 	return 0;
 }
 
 /* find the biggest valid pfn in the range [start_pfn, end_pfn). */
-static unsigned long find_biggest_section_pfn(int nid, struct zone *zone,
-				    unsigned long start_pfn,
-				    unsigned long end_pfn)
+static unsigned long find_biggest_section_pfn(struct zone *zone,
+		unsigned long start_pfn, unsigned long end_pfn)
 {
-	unsigned long pfn;
-
-	/* pfn is the end pfn of a memory section. */
-	pfn = end_pfn - 1;
-	for (; pfn >= start_pfn; pfn -= PAGES_PER_SUBSECTION) {
-		if (unlikely(!pfn_to_online_page(pfn)))
-			continue;
-
-		if (unlikely(pfn_to_nid(pfn) != nid))
-			continue;
-
-		if (zone != page_zone(pfn_to_page(pfn)))
-			continue;
-
-		return pfn;
+	for (; end_pfn >= start_pfn; end_pfn -= PAGES_PER_SUBSECTION) {
+		if (subsection_overlaps_zone(end_pfn - 1, zone))
+			return end_pfn - 1;
 	}
-
 	return 0;
 }
 
@@ -472,7 +462,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 			     unsigned long end_pfn)
 {
 	unsigned long pfn;
-	int nid = zone_to_nid(zone);
 
 	if (zone->zone_start_pfn == start_pfn) {
 		/*
@@ -481,7 +470,7 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 		 * In this case, we find second smallest valid mem_section
 		 * for shrinking zone.
 		 */
-		pfn = find_smallest_section_pfn(nid, zone, end_pfn,
+		pfn = find_smallest_section_pfn(zone, end_pfn,
 						zone_end_pfn(zone));
 		if (pfn) {
 			zone->spanned_pages = zone_end_pfn(zone) - pfn;
@@ -497,7 +486,7 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
 		 * In this case, we find second biggest valid mem_section for
 		 * shrinking zone.
 		 */
-		pfn = find_biggest_section_pfn(nid, zone, zone->zone_start_pfn,
+		pfn = find_biggest_section_pfn(zone, zone->zone_start_pfn,
 					       start_pfn);
 		if (pfn)
 			zone->spanned_pages = pfn - zone->zone_start_pfn + 1;
@@ -557,18 +546,13 @@ void remove_pfn_range_from_zone(struct zone *zone,
 
 	/*
 	 * Zone shrinking code cannot properly deal with ZONE_DEVICE. So
-	 * we will not try to shrink the zones - which is okay as
-	 * set_zone_contiguous() cannot deal with ZONE_DEVICE either way.
+	 * we will not try to shrink it.
 	 */
 	if (zone_is_zone_device(zone))
 		return;
 
-	clear_zone_contiguous(zone);
-
 	shrink_zone_span(zone, start_pfn, start_pfn + nr_pages);
 	update_pgdat_span(pgdat);
-
-	set_zone_contiguous(zone);
 }
 
 /**
@@ -746,8 +730,6 @@ void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
 	struct pglist_data *pgdat = zone->zone_pgdat;
 	int nid = pgdat->node_id;
 
-	clear_zone_contiguous(zone);
-
 	if (zone_is_empty(zone))
 		init_currently_empty_zone(zone, start_pfn, nr_pages);
 	resize_zone_range(zone, start_pfn, nr_pages);
@@ -775,8 +757,6 @@ void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
 	memmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,
 			 MEMINIT_HOTPLUG, altmap, migratetype,
 			 isolate_pageblock);
-
-	set_zone_contiguous(zone);
 }
 
 struct auto_movable_stats {
@@ -1072,6 +1052,7 @@ void adjust_present_page_count(struct page *page, struct memory_group *group,
 	if (early_section(__pfn_to_section(page_to_pfn(page))))
 		zone->present_early_pages += nr_pages;
 	zone->present_pages += nr_pages;
+	zone->pages_with_online_memmap += nr_pages;
 	zone->zone_pgdat->node_present_pages += nr_pages;
 
 	if (group && movable)
diff --git a/mm/mm_init.c b/mm/mm_init.c
index f1afe023e4e72..d63ee554d7eb8 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -799,6 +799,28 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)
 	__init_deferred_page(pfn, nid);
 }
 
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+static bool __init unavailable_pfn_is_online(unsigned long pfn,
+					     unsigned long *last_subsection,
+					     bool *is_online)
+{
+	unsigned long subsection = pfn & PAGE_SUBSECTION_MASK;
+
+	if (subsection != *last_subsection) {
+		*is_online = !!pfn_to_online_page(pfn);
+		*last_subsection = subsection;
+	}
+	return *is_online;
+}
+#else
+static inline bool unavailable_pfn_is_online(unsigned long pfn,
+					     unsigned long *last_subsection,
+					     bool *is_online)
+{
+	return true;
+}
+#endif
+
 /*
  * Only struct pages that correspond to ranges defined by memblock.memory
  * are zeroed and initialized by going through __init_single_page() during
@@ -822,22 +844,27 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)
  *   zone/node above the hole except for the trailing pages in the last
  *   section that will be appended to the zone/node below.
  */
-static void __init init_unavailable_range(unsigned long spfn,
-					  unsigned long epfn,
-					  int zone, int node)
+static unsigned long __init init_unavailable_range(unsigned long spfn,
+						   unsigned long epfn,
+						   int zone, int node)
 {
 	unsigned long pfn;
-	u64 pgcnt = 0;
+	u64 pgcnt = 0, online_pgcnt = 0;
+	unsigned long last_subsection = -1;
+	bool is_online = false;
 
 	for_each_valid_pfn(pfn, spfn, epfn) {
 		__init_single_page(pfn_to_page(pfn), pfn, zone, node);
 		__SetPageReserved(pfn_to_page(pfn));
+		if (unavailable_pfn_is_online(pfn, &last_subsection, &is_online))
+			online_pgcnt++;
 		pgcnt++;
 	}
 
 	if (pgcnt)
 		pr_info("On node %d, zone %s: %lld pages in unavailable ranges\n",
 			node, zone_names[zone], pgcnt);
+	return online_pgcnt;
 }
 
 /*
@@ -934,9 +961,21 @@ static void __init memmap_init_zone_range(struct zone *zone,
 
 	memmap_init_range(end_pfn - start_pfn, nid, zone_id, start_pfn,
 			  zone_end_pfn, MEMINIT_EARLY, NULL, mt, false);
+	zone->pages_with_online_memmap += end_pfn - start_pfn;
+
+	if (*hole_pfn < start_pfn) {
+		unsigned long hole_start_pfn = *hole_pfn;
+		unsigned long pgcnt;
 
-	if (*hole_pfn < start_pfn)
-		init_unavailable_range(*hole_pfn, start_pfn, zone_id, nid);
+		if (hole_start_pfn < zone_start_pfn) {
+			init_unavailable_range(hole_start_pfn, zone_start_pfn,
+					       zone_id, nid);
+			hole_start_pfn = zone_start_pfn;
+		}
+		pgcnt = init_unavailable_range(hole_start_pfn, start_pfn,
+					       zone_id, nid);
+		zone->pages_with_online_memmap += pgcnt;
+	}
 
 	*hole_pfn = end_pfn;
 }
@@ -2195,28 +2234,6 @@ void __init init_cma_pageblock(struct page *page)
 }
 #endif
 
-void set_zone_contiguous(struct zone *zone)
-{
-	unsigned long block_start_pfn = zone->zone_start_pfn;
-	unsigned long block_end_pfn;
-
-	block_end_pfn = pageblock_end_pfn(block_start_pfn);
-	for (; block_start_pfn < zone_end_pfn(zone);
-			block_start_pfn = block_end_pfn,
-			 block_end_pfn += pageblock_nr_pages) {
-
-		block_end_pfn = min(block_end_pfn, zone_end_pfn(zone));
-
-		if (!__pageblock_pfn_to_page(block_start_pfn,
-					     block_end_pfn, zone))
-			return;
-		cond_resched();
-	}
-
-	/* We confirm that there is no hole */
-	zone->contiguous = true;
-}
-
 /*
  * Check if a PFN range intersects multiple zones on one or more
  * NUMA nodes. Specify the @nid argument if it is known that this

gemini-3.1-pro-preview

null

null

							input: 7179
							output: 177
							thoughts: 905
						

**KMSAN Assessment: Memory Hotplug and Contiguous Zone Logic Patch**

Alright, let's break this down. The patch is messing with memory hotplug and the logic around contiguous zones, specifically by adding `pages_with_online_memmap` to the `struct zone` and changing how we determine if a zone is contiguous. It also touches a bunch of functions like `memory_block_online`, `memory_block_offline`, and various PFN manipulation routines. My immediate concern is, does this introduce any opportunities for uninitialized memory reads that KMSAN is specifically designed to catch?

Let's look at the key changes: adding a counter, altering a boolean flag, and updating a few memory management functions. I'm not seeing any new structures being exposed to user space, no complex new data structures being allocated in the kernel and potentially left uninitialized, and no obvious avenues for leaking uninitialized kernel memory to user space. These changes are all about tracking online pages and checking for contiguity within memory zones, not new allocation or handling of uninitialized data on the stack or heap.

If there's a bug here, I suspect it's going to manifest as an out-of-bounds access, a null pointer dereference, or an invalid page access – like trying to use a page structure that doesn't exist or hasn't been properly initialized. KASAN is already going to be my primary tool to address these types of issues, which are the main risks here, since it is tailored to finding these issues. KMSAN is for catching uninitialized reads, which could cause a security risk, particularly if that memory is leaked. But this patch doesn't seem to be changing how we allocate and initialize page structures and memory regions, only how we track their status.

Let's double-check, though, to be safe. `pages_with_online_memmap` is a simple counter. `zone->contiguous` is a boolean. `init_unavailable_range` initializes pages using `__init_single_page` and `__SetPageReserved`. This initialization is critical, and these pages will be initialized upon allocating, or they will be zeroed. The patch updates these counters and flags and manipulates these memory zones, but it isn't changing how these memory zones are allocated or how we initialize their values. The patch does not have any obvious impact on memory initialization, allocation or release, it updates flags for zones that have already been allocated, initialized, and released, and so on.

Therefore, my conclusion is that KMSAN isn't needed here. KASAN and standard kernel debugging tools should be sufficient to catch any issues introduced by these changes. I'm going to set `NeedsKMSAN=false`. My reasoning is this: the patch updates page tracking and contiguous zone logic, which is primarily managing counters and flags related to existing memory structures. It doesn't introduce any new allocation or complex data structures prone to uninitialized memory issues and is not going to leak information to user space. Bugs will likely be memory access errors that KASAN can find.

{
  "KMSANReasoning": "The patch modifies memory hotplug and zone contiguous tracking logic by introducing `pages_with_online_memmap` to `struct zone` and updating how `zone_is_contiguous` is evaluated. These changes involve updating counters and boolean flags, and do not introduce new stack or heap allocations that could be left uninitialized. There are no structures copied to user space, so there is no risk of info-leaks. Any bugs introduced by these changes (e.g., incorrect contiguous zone evaluation) would likely result in out-of-bounds accesses, NULL pointer dereferences, or invalid page struct accesses, which are effectively caught by KASAN and standard kernel debugging tools. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch modifies memory hotplug and zone contiguous tracking logic by introducing `pages_with_online_memmap` to `struct zone` and updating how `zone_is_contiguous` is evaluated. These changes involve updating counters and boolean flags, and do not introduce new stack or heap allocations that could be left uninitialized. There are no structures copied to user space, so there is no risk of info-leaks. Any bugs introduced by these changes (e.g., incorrect contiguous zone evaluation) would likely result in out-of-bounds accesses, NULL pointer dereferences, or invalid page struct accesses, which are effectively caught by KASAN and standard kernel debugging tools. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}