[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH] xen/page_alloc: Keep away MFN 0 from the buddy allocator

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>

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.).

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.