arch/powerpc/mm/init_64.c | 8 -------- arch/s390/mm/vmem.c | 3 +-- arch/sparc/mm/init_64.c | 20 -------------------- include/linux/bootmem_info.h | 1 - mm/Kconfig | 2 +- mm/bootmem_info.c | 25 ++----------------------- 6 files changed, 4 insertions(+), 55 deletions(-)
We want to remove CONFIG_HAVE_BOOTMEM_INFO_NODE. As a first step,
let's limit the remaining harm to x86 and core code, removing
sparc, ppc and s390 leftovers, starting the stepwise removal by removing
and simplifying some code.
Once a related x86 vmemmap fix [1] is in, we can merge part 2 that will
remove CONFIG_HAVE_BOOTMEM_INFO_NODE entirely.
Tested on x86-64 with hugetlb vmemmap optimization in combination with
KMEMLEAK, making sure that the problem reported in dd0ff4d12dd2 ("bootmem:
remove the vmemmap pages from kmemleak in put_page_bootmem") does not
reappear -- hoping I managed to trigger the original problem.
Heavily cross-compiled, but let's let build bots run on it for a bit.
[1] https://lore.kernel.org/r/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
David Hildenbrand (Arm) (8):
sparc/mm: remove register_page_bootmem_info()
mm/bootmem_info: drop initialization of page->lru
mm/bootmem_info: stop using PG_private
mm/bootmem_info: remove call to kmemleak_free_part_phys()
mm/bootmem_info: stop marking the pgdat as NODE_INFO
mm/bootmem_info: stop marking mem_section_usage as MIX_SECTION_INFO
s390/mm: use free_reserved_page() in vmem_free_pages()
powerpc/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE
arch/powerpc/mm/init_64.c | 8 --------
arch/s390/mm/vmem.c | 3 +--
arch/sparc/mm/init_64.c | 20 --------------------
include/linux/bootmem_info.h | 1 -
mm/Kconfig | 2 +-
mm/bootmem_info.c | 25 ++-----------------------
6 files changed, 4 insertions(+), 55 deletions(-)
---
base-commit: e9dd96806dbc2d50a66770b6a86962bd5d601153
change-id: 20260511-bootmem_info_prep-bfc0e7a5b87e
--
Cheers,
David
On Mon 11-05-26 16:05:28, David Hildenbrand wrote:
> We want to remove CONFIG_HAVE_BOOTMEM_INFO_NODE. As a first step,
> let's limit the remaining harm to x86 and core code, removing
> sparc, ppc and s390 leftovers, starting the stepwise removal by removing
> and simplifying some code.
>
> Once a related x86 vmemmap fix [1] is in, we can merge part 2 that will
> remove CONFIG_HAVE_BOOTMEM_INFO_NODE entirely.
>
> Tested on x86-64 with hugetlb vmemmap optimization in combination with
> KMEMLEAK, making sure that the problem reported in dd0ff4d12dd2 ("bootmem:
> remove the vmemmap pages from kmemleak in put_page_bootmem") does not
> reappear -- hoping I managed to trigger the original problem.
>
> Heavily cross-compiled, but let's let build bots run on it for a bit.
>
> [1] https://lore.kernel.org/r/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
> David Hildenbrand (Arm) (8):
> sparc/mm: remove register_page_bootmem_info()
> mm/bootmem_info: drop initialization of page->lru
> mm/bootmem_info: stop using PG_private
> mm/bootmem_info: remove call to kmemleak_free_part_phys()
> mm/bootmem_info: stop marking the pgdat as NODE_INFO
> mm/bootmem_info: stop marking mem_section_usage as MIX_SECTION_INFO
> s390/mm: use free_reserved_page() in vmem_free_pages()
> powerpc/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE
>
> arch/powerpc/mm/init_64.c | 8 --------
> arch/s390/mm/vmem.c | 3 +--
> arch/sparc/mm/init_64.c | 20 --------------------
> include/linux/bootmem_info.h | 1 -
> mm/Kconfig | 2 +-
> mm/bootmem_info.c | 25 ++-----------------------
> 6 files changed, 4 insertions(+), 55 deletions(-)
Good clean up. Feel free to add
Acked-by: Michal Hocko <mhocko@suse.com>
to all patches but kmemleak one which I do not feel qualified to judge.
Thanks!
--
Michal Hocko
SUSE Labs
On 5/12/26 09:46, Michal Hocko wrote:
> On Mon 11-05-26 16:05:28, David Hildenbrand wrote:
>> We want to remove CONFIG_HAVE_BOOTMEM_INFO_NODE. As a first step,
>> let's limit the remaining harm to x86 and core code, removing
>> sparc, ppc and s390 leftovers, starting the stepwise removal by removing
>> and simplifying some code.
>>
>> Once a related x86 vmemmap fix [1] is in, we can merge part 2 that will
>> remove CONFIG_HAVE_BOOTMEM_INFO_NODE entirely.
>>
>> Tested on x86-64 with hugetlb vmemmap optimization in combination with
>> KMEMLEAK, making sure that the problem reported in dd0ff4d12dd2 ("bootmem:
>> remove the vmemmap pages from kmemleak in put_page_bootmem") does not
>> reappear -- hoping I managed to trigger the original problem.
>>
>> Heavily cross-compiled, but let's let build bots run on it for a bit.
>>
>> [1] https://lore.kernel.org/r/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org
>>
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>> ---
>> David Hildenbrand (Arm) (8):
>> sparc/mm: remove register_page_bootmem_info()
>> mm/bootmem_info: drop initialization of page->lru
>> mm/bootmem_info: stop using PG_private
>> mm/bootmem_info: remove call to kmemleak_free_part_phys()
>> mm/bootmem_info: stop marking the pgdat as NODE_INFO
>> mm/bootmem_info: stop marking mem_section_usage as MIX_SECTION_INFO
>> s390/mm: use free_reserved_page() in vmem_free_pages()
>> powerpc/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE
>>
>> arch/powerpc/mm/init_64.c | 8 --------
>> arch/s390/mm/vmem.c | 3 +--
>> arch/sparc/mm/init_64.c | 20 --------------------
>> include/linux/bootmem_info.h | 1 -
>> mm/Kconfig | 2 +-
>> mm/bootmem_info.c | 25 ++-----------------------
>> 6 files changed, 4 insertions(+), 55 deletions(-)
>
> Good clean up. Feel free to add
> Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> to all patches but kmemleak one which I do not feel qualified to judge.
It's black magic to me as well. I tried to test that scenario in particular and
was not able to trigger the problem.
--
Cheers,
David
On Mon, May 11, 2026 at 04:05:28PM +0200, David Hildenbrand (Arm) wrote:
> We want to remove CONFIG_HAVE_BOOTMEM_INFO_NODE. As a first step,
> let's limit the remaining harm to x86 and core code, removing
> sparc, ppc and s390 leftovers, starting the stepwise removal by removing
> and simplifying some code.
>
> Once a related x86 vmemmap fix [1] is in, we can merge part 2 that will
> remove CONFIG_HAVE_BOOTMEM_INFO_NODE entirely.
>
> Tested on x86-64 with hugetlb vmemmap optimization in combination with
> KMEMLEAK, making sure that the problem reported in dd0ff4d12dd2 ("bootmem:
> remove the vmemmap pages from kmemleak in put_page_bootmem") does not
> reappear -- hoping I managed to trigger the original problem.
>
> Heavily cross-compiled, but let's let build bots run on it for a bit.
>
> [1] https://lore.kernel.org/r/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org
>
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Awesome cleanup David, thanks for doing this ;-)
--
Oscar Salvador
SUSE Labs
On 5/12/26 10:45, Oscar Salvador wrote:
> On Mon, May 11, 2026 at 04:05:28PM +0200, David Hildenbrand (Arm) wrote:
>> We want to remove CONFIG_HAVE_BOOTMEM_INFO_NODE. As a first step,
>> let's limit the remaining harm to x86 and core code, removing
>> sparc, ppc and s390 leftovers, starting the stepwise removal by removing
>> and simplifying some code.
>>
>> Once a related x86 vmemmap fix [1] is in, we can merge part 2 that will
>> remove CONFIG_HAVE_BOOTMEM_INFO_NODE entirely.
>>
>> Tested on x86-64 with hugetlb vmemmap optimization in combination with
>> KMEMLEAK, making sure that the problem reported in dd0ff4d12dd2 ("bootmem:
>> remove the vmemmap pages from kmemleak in put_page_bootmem") does not
>> reappear -- hoping I managed to trigger the original problem.
>>
>> Heavily cross-compiled, but let's let build bots run on it for a bit.
>>
>> [1] https://lore.kernel.org/r/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org
>>
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>
> Awesome cleanup David, thanks for doing this ;-)
Thanks for the review, I'm sure you'll enjoy part 2 :)
--
Cheers,
David
© 2016 - 2026 Red Hat, Inc.