[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 |