[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty bitmap
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |