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 <[email protected]> Signed-off-by: Julien Grall <[email protected]> --- Cc: [email protected] Cc: [email protected] 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
