Re: [PATCH 07/10] x86/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Incomplete feature removal leaves behind dead code.

Pre-existing issues:
- [High] Page tables and vmemmap target pages are freed to the buddy allocator before their page table entries are cleared, causing a Use-After-Free race with hardware page table walkers.
--

--- Patch [7]: [PATCH 07/10] x86/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE ---
commit 4f73978273a221d985e72d75af30f38db0280de6
Author: David Hildenbrand (Arm) <david@kernel.org>

x86/mm: remove CONFIG_HAVE_BOOTMEM_INFO_NODE
    
CONFIG_HAVE_BOOTMEM_INFO_NODE now essentially doesn't do anything.
So let's remove support for CONFIG_HAVE_BOOTMEM_INFO_NODE.

> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 1b17dcf781e66..ab4c5a02326f7 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c

[ ... ]

> diff --git a/mm/Kconfig b/mm/Kconfig
> index f794a341d7422..592003a258bad 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -590,7 +590,6 @@ endchoice
>  
>  config MEMORY_HOTREMOVE
>  	bool "Allow for memory hot remove"
> -	select HAVE_BOOTMEM_INFO_NODE if X86_64

[Severity: Medium]
Since the intention of this commit is to remove support for 
CONFIG_HAVE_BOOTMEM_INFO_NODE, should the definition of the config itself 
also be deleted?

Currently, `config HAVE_BOOTMEM_INFO_NODE` remains in mm/Kconfig as a dead 
`def_bool n` option. Additionally, `mm/bootmem_info.c` and its build rule 
`obj-$(CONFIG_HAVE_BOOTMEM_INFO_NODE) += bootmem_info.o` in mm/Makefile are 
left behind as dead code.

>  	depends on MEMORY_HOTPLUG
>  	select MIGRATION
>  

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the memory 
hot-remove code in arch/x86/mm/init_64.c, I noticed that page tables and 
vmemmap target pages appear to be freed to the buddy allocator before their 
page table entries are actually cleared.

In arch/x86/mm/init_64.c:free_pte_table():

	/* free a pte table */
	free_pagetable(pmd_page(*pmd));
	spin_lock(&init_mm.page_table_lock);
	pmd_clear(pmd);

And similarly in arch/x86/mm/init_64.c:remove_pte_table():

			if (!direct)
				/* We never populate base pages from the altmap. */
				free_vmemmap_pages(pte_page(*pte), 0, NULL);

			spin_lock(&init_mm.page_table_lock);
			pte_clear(&init_mm, addr, pte);

Does this open a use-after-free race window where hardware page table walkers 
or speculative execution could access the recently-freed memory and interpret 
arbitrary data as page tables before the clear operation completes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-bootmem_info_part2-v1-0-156ce4986598@kernel.org?part=7