| Message ID | 20240605082049.973242-1-rppt@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/memory_hotplug: Drop memblock_phys_free() call in try_remove_memory() | expand |
On Wed, Jun 05, 2024 at 11:20:49AM +0300, Mike Rapoport wrote: > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > The call for memblock_phys_free() in try_remove_memory() does not balance > any call to memblock_alloc() (or memblock_reserve() for that matter). > > There are no memblock_reserve() calls in mm/memory_hotplug.c, no memblock > allocations possible after mm_core_init(), and even if memblock_add_node() > called from add_memory_resource() would need to allocate memory, that > memory would ba allocated from slab. > > The patch f9126ab9241f ("memory-hotplug: fix wrong edge when hot add a new > node") that introduced that call to memblock_free() does not provide > adequate description why that was required and tinkering with memblock in > the context of memory hotplug on x86 seems bogus because x86 never kept > memblock after boot anyway. > > Drop memblock_phys_free() call in try_remove_memory(). > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > [rppt: rewrite the commit message] > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: Oscar Salvador <osalvador@suse.de>
On Wed, Jun 05, 2024 at 11:20:49AM +0300, Mike Rapoport wrote: > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > The call for memblock_phys_free() in try_remove_memory() does not balance > any call to memblock_alloc() (or memblock_reserve() for that matter). > > There are no memblock_reserve() calls in mm/memory_hotplug.c, no memblock > allocations possible after mm_core_init(), and even if memblock_add_node() > called from add_memory_resource() would need to allocate memory, that > memory would ba allocated from slab. > > The patch f9126ab9241f ("memory-hotplug: fix wrong edge when hot add a new > node") that introduced that call to memblock_free() does not provide > adequate description why that was required and tinkering with memblock in > the context of memory hotplug on x86 seems bogus because x86 never kept > memblock after boot anyway. > > Drop memblock_phys_free() call in try_remove_memory(). > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > [rppt: rewrite the commit message] > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: Oscar Salvador <osalvador@suse.de> > --- > mm/memory_hotplug.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 431b1f6753c0..e0d49f128e0d 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -2283,10 +2283,8 @@ static int __ref try_remove_memory(u64 start, u64 size) > remove_memory_blocks_and_altmaps(start, size); > } > > - if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) { > - memblock_phys_free(start, size); > + if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) > memblock_remove(start, size); > - } > > release_mem_region_adjustable(start, size); > > -- > 2.43.0 >
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 431b1f6753c0..e0d49f128e0d 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -2283,10 +2283,8 @@ static int __ref try_remove_memory(u64 start, u64 size) remove_memory_blocks_and_altmaps(start, size); } - if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) { - memblock_phys_free(start, size); + if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) memblock_remove(start, size); - } release_mem_region_adjustable(start, size);