[Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty bitmap

[Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>]

 xen/arch/x86/mm/hap/hap.c |  15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)


hap_log_dirty_init unconditionally sets the top of the log dirty
bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
then leaked, and the host crashes on an ASSERT when the domain is
cleaned up. Fixing it here.

Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>

diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
 void hap_logdirty_init(struct domain *d)
 {
     struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-    if ( paging_mode_log_dirty(d) && dirty_vram )
+    if ( paging_mode_log_dirty(d) )
     {
-        paging_log_dirty_disable(d);
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        if ( dirty_vram )
+        {
+            paging_log_dirty_disable(d);
+            xfree(dirty_vram);
+            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        } else {
+            /* We still need to clean up the bitmap, because
+             * init below will overwrite it */
+            paging_free_log_dirty_bitmap(d);
+        }
     }
 
     /* Reinitialize logdirty mechanism */

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel