Re: [PATCH] x86/mm: Check return value from memblock_phys_alloc_range()
From: Ingo Molnar
Date: Tue Nov 19 2024 - 06:14:31 EST
* gldrk <me@xxxxxxxxxx> wrote:
> At least with CONFIG_PHYSICAL_START=0x100000, if there is < 4 MiB of contiguous
> free memory available at this point, the kernel will crash and burn because
> memblock_phys_alloc_range returns 0 on failure, which leads memblock_phys_free
> to throw the first 4 MiB of physical memory to the wolves. At a minimum it
> should fail gracefully with a meaningful diagnostic, but in fact everything
> seems to work fine without the weird reserve allocation.
>
> ---
> arch/x86/mm/init.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index eb503f5..3696770 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -640,8 +640,13 @@ static void __init memory_map_top_down(unsigned long
> map_start,
> */
> addr = memblock_phys_alloc_range(PMD_SIZE, PMD_SIZE, map_start,
> map_end);
> - memblock_phys_free(addr, PMD_SIZE);
> - real_end = addr + PMD_SIZE;
> + if (unlikely(addr < map_start)) {
> + pr_warn("Failed to release memory for alloc_low_pages()");
> + real_end = ALIGN_DOWN(map_end, PMD_SIZE);
> + } else {
> + memblock_phys_free(addr, PMD_SIZE);
> + real_end = addr + PMD_SIZE;
> + }
Makes sense to fix this bug I suppose, but the usual error check
pattern for memblock_phys_alloc_range() failure would not be 'addr <
map_start' but !addr.
( If memblock_phys_alloc_range() succeeds but returns an address below
'map_start', that would be a different failure I guess. )
Also, no need to add the 'unlikely()' I suspect - this is early boot
code, micro-performance of branching is immaterial.
Just curious: what type of system has < 4 MiB of contiguous free memory
available in early boot? Or was it something intentionally constrained
via qemu?
Thanks,
Ingo