]> xenbits.xensource.com Git - pvdrivers/win/xenbus.git/commitdiff
Don't BUG() just because we can't get a super-page
authorPaul Durrant <paul.durrant@citrix.com>
Tue, 24 Sep 2019 12:40:58 +0000 (13:40 +0100)
committerPaul Durrant <paul.durrant@citrix.com>
Tue, 24 Sep 2019 12:46:29 +0000 (13:46 +0100)
When XENBUS is unloaded, it is necessary to re-populate the memory hole
that was created to host the shared info page, grant table shared frames,
etc. The hole is created by doing an order 9 XENMEM_decrease_reservation,
but this does not necessarily mean that Xen can re-populate it with an
order 9 allocation (i.e. a 2M super-page). Currently, such a failure will
cause an immediate BUG(), whereas what the code should do is to re-try
using order 0 (i.e. normal 4k page) allocations, and only BUG() if that
doesn't work.

This patch fixes the issue.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
src/xenbus/fdo.c

index 7047f6a175f62e81a37307d3f98932e94ef6da66..27837b2935876e9952b547368a79b4375906c610 100644 (file)
@@ -3096,6 +3096,7 @@ FdoDestroyHole(
     PFN_NUMBER      Pfn;
     LONGLONG        Start;
     ULONG           Count;
+    ULONG           Index;
     NTSTATUS        status;
 
     Mdl = Fdo->Mdl;
@@ -3107,9 +3108,18 @@ FdoDestroyHole(
 
     Trace("%08x - %08x\n", Start, Start + Count - 1);
 
-    if (MemoryPopulatePhysmap(PAGE_ORDER_2M, 1, &Pfn) != 1)
-        BUG("FAILED TO RE-POPULATE HOLE");
+    ASSERT3U(Count & ((1u << PAGE_ORDER_2M) - 1), ==, 0);
+    if (MemoryPopulatePhysmap(PAGE_ORDER_2M, 1, &Pfn) == 1)
+        goto done;
+
+    for (Index = 0; Index < Count; Index++) {
+        if (MemoryPopulatePhysmap(PAGE_ORDER_4K, 1, &Pfn) != 1)
+            BUG("FAILED TO RE-POPULATE HOLE");
 
+        Pfn++;
+    }
+
+done:
     status = XENBUS_RANGE_SET(Get,
                               &Fdo->RangeSetInterface,
                               Fdo->RangeSet,