Re: [Xen-devel] [PATCH 01/27] xen/x86: numa: Don't check alloc_boot_pages return

[Andre Przywara <andre.przywara@xxxxxxx>]

Hi,

On 14/08/17 15:23, Julien Grall wrote:
> alloc_boot_pages will panic if it is not possible to allocate. So the
> check in the caller is pointless.

More than that I don't see why "0" couldn't be a valid MFN. At least the
code in alloc_boot_pages() doesn't treat it specially, so it doesn't
signal an error condition in the first place.

> Signed-off-by: Julien Grall <julien.grall@xxxxxxx>

Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>

Cheers,
Andre.

> ---
> 
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
>  xen/arch/x86/numa.c | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
> index d45196fafc..ffeba6e180 100644
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -101,14 +101,6 @@ static int __init allocate_cachealigned_memnodemap(void)
>      unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
>      unsigned long mfn = alloc_boot_pages(size, 1);
>  
> -    if ( !mfn )
> -    {
> -        printk(KERN_ERR
> -               "NUMA: Unable to allocate Memory to Node hash map\n");
> -        memnodemapsize = 0;
> -        return -1;
> -    }
> -
>      memnodemap = mfn_to_virt(mfn);
>      mfn <<= PAGE_SHIFT;
>      size <<= PAGE_SHIFT;
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel