linux.git/mm/memory_hotplug.c, branch v7.3-rc1

mm/memory_hotplug: add offline_and_remove_memory_ranges()

2026-08-07T01:56:59+00:00

offline_and_remove_memory() handles a single contiguous range.

Callers that manage a device composed of several ranges (dax/kmem)
currently have to call it in a loop, which gives up atomicity.

In addition to pushing rollback logic into the driver, the lack of
atomicity creates a race condition between system daemons trying to manage
the same resource:

   - Manager 1:  Offlines memory blocks.    Removes device.
                                        ^^^^
   - Manager 2:  Detects offline memory blocks, re-onlines them.

Add offline_and_remove_memory_ranges(), which takes an array of ranges and
processes them as one operation under a single lock_device_hotplug():

  - Phase 1 offlines every block of every range.
  - Phase 2 removes the ranges only if all ranges are offline.
  - If any offline fails, the whole operation is reverted.

This gives callers all-or-nothing semantics for the offline step, so a
failed or interrupted unplug leaves the device in a consistent state.

This also resolves the battling managers race - the second manager's
operation simply fails when the block is destroyed / cannot be onlined.

offline_and_remove_memory() becomes a thin wrapper that passes its single
range to the new helper, so the offline/rollback logic lives in one place.

Link: https://lore.kernel.org/20260712154505.3564379-7-gourry@gourry.net
Signed-off-by: Gregory Price 
Suggested-by: David Hildenbrand (Arm) 
Reviewed-by: Dave Jiang 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Dan Williams 
Cc: Alison Schofield 
Cc: Danilo Krummrich 
Cc: Greg Kroah-Hartman 
Cc: Hannes Reinecke 
Cc: Liam R. Howlett 
Cc: Lorenzo Stoakes 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Oscar Salvador 
Cc: Pankaj Gupta 
Cc: "Rafael J. Wysocki" 
Cc: Shuah Khan 
Cc: Suren Baghdasaryan 
Cc: Vishal Verma 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg

2026-08-07T01:56:59+00:00

Existing callers of add_memory_driver_managed cannot select the preferred
online type (ZONE_NORMAL vs ZONE_MOVABLE), requiring it to hot-add memory
as offline blocks, and then follow up by onlining each memory block
individually.

Most drivers prefer the system default, but the CXL driver wants to plumb
a preferred policy through the dax kmem driver.

Refactor APIs to add a new interface which allows the dax kmem module to
select a preferred policy.

Overriding the configured auto-online policy is only safe for known
in-tree modules, where we know the override reflects a different,
user-requested policy.  We do not want arbitrary out-of-tree drivers
silently overriding the system-wide onlining policy, so restrict the new
interface to the kmem module using EXPORT_SYMBOL_FOR_MODULES() rather than
a plain EXPORT_SYMBOL_GPL().  Other in-tree modules (e.g.  cxl_core) can
be added to the allowed list as the need arises.

Refactor add_memory_driver_managed, extract __add_memory_driver_managed
- Add proper kernel-doc for add_memory_driver_managed while refactoring
- New helper accepts an explicit online_type.
- New helper validates online_type is between OFFLINE and ONLINE_MOVABLE

Refactor: add_memory_resource, extract __add_memory_resource
- new helper accepts an explicit online_type

Original APIs now explicitly pass the system-default to new helpers.

No functional change for existing users.

Link: https://lore.kernel.org/20260712154505.3564379-6-gourry@gourry.net
Signed-off-by: Gregory Price 
Acked-by: David Hildenbrand (Arm) 
Reviewed-by: Pankaj Gupta 
Reviewed-by: Dave Jiang 
Reviewed-by: Dan Williams 
Cc: Alison Schofield 
Cc: Danilo Krummrich 
Cc: Greg Kroah-Hartman 
Cc: Hannes Reinecke 
Cc: Liam R. Howlett 
Cc: Lorenzo Stoakes 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Oscar Salvador 
Cc: "Rafael J. Wysocki" 
Cc: Shuah Khan 
Cc: Suren Baghdasaryan 
Cc: Vishal Verma 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

mm/memory_hotplug: export mhp_get_default_online_type

2026-08-07T01:56:59+00:00

Drivers which may pass hotplug policy down to DAX need MMOP_ symbols and
the mhp_get_default_online_type function for hotplug use cases.

Some drivers (cxl) co-mingle their hotplug and devdax use-cases into the
same driver code, and chose the dax_kmem path as the default driver path -
making it difficult to require hotplug as a predicate to building the
overall driver (it may break other non-hotplug use-cases).

Export mhp_get_default_online_type function to allow these drivers to
build when hotplug is disabled and still use the DAX use case.

In the built-out case we simply return MMOP_OFFLINE as it's
non-destructive.  The internal function can never return -1 either, so we
choose this to allow for defining the function with 'enum mmop'.

Link: https://lore.kernel.org/20260712154505.3564379-5-gourry@gourry.net
Signed-off-by: Gregory Price 
Reviewed-by: Dave Jiang 
Reviewed-by: Dan Williams 
Acked-by: David Hildenbrand (Arm) 
Cc: Alison Schofield 
Cc: Danilo Krummrich 
Cc: Greg Kroah-Hartman 
Cc: Hannes Reinecke 
Cc: Liam R. Howlett 
Cc: Lorenzo Stoakes 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Oscar Salvador 
Cc: Pankaj Gupta 
Cc: "Rafael J. Wysocki" 
Cc: Shuah Khan 
Cc: Suren Baghdasaryan 
Cc: Vishal Verma 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

mm/memory_hotplug: pass online_type to online_memory_block() via arg

2026-08-07T01:56:58+00:00

Modify online_memory_block() to accept the online type through its arg
parameter rather than calling mhp_get_default_online_type() internally.

This prepares for allowing callers to specify explicit online types.

Update the caller in add_memory_resource() to pass the default online
type via a local variable.

No functional change.

Link: https://lore.kernel.org/20260712154505.3564379-4-gourry@gourry.net
Signed-off-by: Gregory Price 
Acked-by: David Hildenbrand (Red Hat) 
Reviewed-by: Pankaj Gupta 
Reviewed-by: Dave Jiang 
Reviewed-by: Dan Williams 
Cc: Alison Schofield 
Cc: Danilo Krummrich 
Cc: Greg Kroah-Hartman 
Cc: Hannes Reinecke 
Cc: Liam R. Howlett 
Cc: Lorenzo Stoakes 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Oscar Salvador 
Cc: "Rafael J. Wysocki" 
Cc: Shuah Khan 
Cc: Suren Baghdasaryan 
Cc: Vishal Verma 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

mm: split out mm_init and memblock declarations from internal.h

2026-08-05T02:18:45+00:00

Patch series "mm: split a couple of headers from internal.h", v2.

mm/internal.h becomes more and more bloated.

Split declarations related to mm_init, memblock, vmalloc and sparse into
new headers.


This patch (of 3):

mm/internal.h becomes more and more bloated.

Move declarations for related to mm/mm_init.c and mm/memblock.c to a new
mm/mm_init.h header.

No functional changes.

[rppt@kernel.org: split stubfs from internal.h to mm_init.h]
  Link: https://lore.kernel.org/alJd1BLypyK9Mpaw@kernel.org
Link: https://lore.kernel.org/20260709-internal-h-v2-0-695631425968@kernel.org
Link: https://lore.kernel.org/20260709-internal-h-v2-1-695631425968@kernel.org
Signed-off-by: Mike Rapoport (Microsoft) 
Acked-by: Muchun Song 
Acked-by: Vlastimil Babka (SUSE) 
Acked-by: David Hildenbrand (Arm) 
Acked-by: Lorenzo Stoakes 
Acked-by: Pratyush Yadav 
Acked-by: SJ Park 
Cc: Alexander Graf 
Cc: Alexander Potapenko 
Cc: Brendan Jackman 
Cc: Brendan Jackman 
Cc: Dennis Zhou 
Cc: Dmitry Vyukov 
Cc: Johannes Weiner 
Cc: Liam R. Howlett 
Cc: Marco Elver 
Cc: Michal Hocko 
Cc: Oscar Salvador 
Cc: Pasha Tatashin 
Cc: Suren Baghdasaryan 
Cc: Tejun Heo 
Cc: "Uladzislau Rezki (Sony)" 
Cc: Zi Yan 
Signed-off-by: Andrew Morton

mm: split out internal page_alloc.h

2026-07-31T02:40:41+00:00

internal.h is a bit bloated, seems like time for a page_alloc.h.

Where it wasn't obvious, the heuristic for deciding what goes into this
new header was "does it support/correspond to a definition in
mm/page_alloc.c?"

Only need to include it from ~20 .c files out of ~150 so this does seem
like a genuine reduction in scopes, which is nice. And there's no
circular internal.h<->page_alloc.h dependency, so it seems worthwhile to
split this up before that inevitably emerges!

Link: https://lore.kernel.org/20260703-alloc-trylock-v5-4-c87b714e19d3@google.com
Signed-off-by: Brendan Jackman 
Suggested-by: "David Hildenbrand (Arm)" 
Link: https://lore.kernel.org/all/41e92bab-6882-401a-8de9-154adbdcfb36@kernel.org/
Reviewed-by: Vlastimil Babka (SUSE) 
Acked-by: Zi Yan 
Signed-off-by: Andrew Morton

mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug

2026-07-31T02:40:31+00:00

We miss a failed allocation check for pgdat->per_cpu_nodestats, which
results in a NULL deref when we offset into the per-cpu area.

Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at
boot_nodestats so a later online can retry the allocation.

hotadd_init_pgdat() returns NULL on failure, which __try_online_node()
already maps to -ENOMEM.

On failure nothing needs to be unwound:
  - the node is never marked online
  - per_cpu_nodestats is left pointing at boot_nodestats
  - __add_memory_resource() cleans up pending memblock resources
  - later online attempts retry the per_cpu_nodestats allocation

Link: https://lore.kernel.org/20260701221613.2818148-1-gourry@gourry.net
Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats")
Signed-off-by: Gregory Price 
Reported-by: Sashiko 
Link: https://sashiko.dev/#/patchset/20260627202243.758289-1-gourry%40gourry.net
Acked-by: David Hildenbrand (Arm) 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Mike Rapoport 
Cc: Oscar Salvador 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

drivers/base/memory: make memory block get/put explicit

2026-06-02T22:22:12+00:00

Rename the memory block lookup helper to make the acquired reference
explicit, add memory_block_put() to wrap put_device(), remove
find_memory_block(), and use memory_block_get() as the single block-id
based lookup interface.

This makes it clearer to callers that a successful lookup holds a
reference that must be dropped, reducing the chance of forgetting the
matching put and leaking the memory block device reference.

Link: https://lore.kernel.org/linux-mm/7887915D-E598-42B3-9AFE-BFFBACE8DE2D@linux.dev/#t
Link: https://lore.kernel.org/20260512072635.3969576-1-songmuchun@bytedance.com
Signed-off-by: Muchun Song 
Acked-by: Oscar Salvador 
Acked-by: David Hildenbrand (Arm) 
Acked-by: Michal Hocko 
Tested-by: Donet Tom 
Reviewed-by: Lorenzo Stoakes 
Tested-by: Sumanth Korikkar  #s390
Cc: Richard Cheng 
Acked-by: Mike Rapoport (Microsoft) 
Cc: Alexander Gordeev 
Cc: Christian Borntraeger 
Cc: Danilo Krummrich 
Cc: Doug Anderson 
Cc: Greg Kroah-Hartman 
Cc: Heiko Carstens 
Cc: Kees Cook 
Cc: Liam R. Howlett 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: "Rafael J. Wysocki" 
Cc: Suren Baghdasaryan 
Cc: Sven Schnelle 
Cc: Vasily Gorbik 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

mm/memory_hotplug: factor out altmap freeing checks

2026-06-02T22:22:10+00:00

Use a small helper to centralize altmap freeing after verifying that all
vmemmap pages were released.  This keeps the check consistent between the
normal teardown path and the memory hotplug error paths.

Link: https://lore.kernel.org/20260511084307.1827127-1-songmuchun@bytedance.com
Signed-off-by: Muchun Song 
Suggested-by: David Hildenbrand (Arm) 
Acked-by: David Hildenbrand (Arm) 
Acked-by: Oscar Salvador 
Reviewed-by: Donet Tom 
Signed-off-by: Andrew Morton

mm/sparse-vmemmap: pass @pgmap argument to memory deactivation paths

2026-05-29T04:04:54+00:00

Currently, the memory hot-remove call chain -- arch_remove_memory(),
__remove_pages(), sparse_remove_section() and section_deactivate() -- does
not carry the struct dev_pagemap pointer.  This prevents the lower levels
from knowing whether the section was originally populated with vmemmap
optimizations (e.g., DAX with vmemmap optimization enabled).

Without this information, we cannot call vmemmap_can_optimize() to
determine if the vmemmap pages were optimized.  As a result, the vmemmap
page accounting during teardown will mistakenly assume a non-optimized
allocation, leading to incorrect memmap statistics.

To lay the groundwork for fixing the vmemmap page accounting, we need to
pass the @pgmap pointer down to the deactivation location.  Plumb the
@pgmap argument through the APIs of arch_remove_memory(), __remove_pages()
and sparse_remove_section(), mirroring the corresponding *_activate()
paths.

Link: https://lore.kernel.org/20260428081855.1249045-4-songmuchun@bytedance.com
Signed-off-by: Muchun Song 
Acked-by: Mike Rapoport (Microsoft) 
Reviewed-by: Oscar Salvador 
Acked-by: David Hildenbrand (Arm) 
Acked-by: Liam R. Howlett 
Cc: "Aneesh Kumar K.V" 
Cc: Joao Martins 
Cc: Lorenzo Stoakes 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Nicholas Piggin 
Cc: Suren Baghdasaryan 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton