|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/page_alloc: Keep away MFN 0 from the buddy allocator
On Fri, 9 Aug 2019, Julien Grall wrote:
> Combining of buddies happens only such that the resulting larger buddy
> is still order-aligned. To cross a zone boundary while merging, the
> implication is that both the buddy [0, 2^n-1] and the buddy
> [2^n, 2^(n+1)] are free.
>
> Ideally we want to fix the allocator, but for now we can just prevent
> adding the MFN 0 in the allocator.
>
> On x86, the MFN 0 is already kept away from the buddy allocator. So the
> bug can only happen on Arm platform where the first memory bank is
> starting at 0.
>
> As this is a specific to the allocator, the MFN 0 is removed in the common
> code
> to cater all the architectures (current and future).
>
> Reported-by: Jeff Kubascik <jeff.kubascik@xxxxxxxxxxxxxxx>
> Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
I could reproduce the problem and I confirm that this patch fixes it:
Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Tested-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> ---
> Cc: Jarvis.Roach@xxxxxxxxxxxxxxx
> Cc: Stewart.Hildebrand@xxxxxxxxxxxxxxx
>
> I am not sure I fully understood the exact problem when MFN 0 is
> given to the allocator. Feel free to suggest a better explanation.
>
> Can anyone able to reproduce the bug test where the patch
> effectively solve the crash?
> ---
> xen/common/page_alloc.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 453b303b5b..42b8a8ce23 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1759,6 +1759,18 @@ static void init_heap_pages(
> bool idle_scrub = false;
>
> /*
> + * Keep MFN 0 away from the buddy allocator to avoid crossing zone
> + * boundary when merging two buddies.
> + */
> + if ( !mfn_x(page_to_mfn(pg)) )
> + {
> + if ( nr_pages-- <= 1 )
> + return;
> + pg++;
> + }
> +
> +
> + /*
> * Some pages may not go through the boot allocator (e.g reserved
> * memory at boot but released just after --- kernel, initramfs,
> * etc.).
> --
> 2.11.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |