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

[Xen-devel] [PATCH] x86 shadow: fix race when domain is dying



There are some cases that shadow_write_p2m_entry() is called after
the domain is killed. It causes Xen to crash.

- The race between xc_map_foreign_batch from qemu-dm and "xm destroy" command.
The actual console log:
(XEN) Xen call trace:
(XEN)    [<ffff82c4801c012e>] hash_foreach+0x87/0x17e
(XEN)    [<ffff82c4801c0362>] sh_remove_all_mappings+0x13d/0x22f
(XEN)    [<ffff82c4801c913d>] shadow_write_p2m_entry+0x14f/0x390
(XEN)    [<ffff82c4801bc73a>] p2m_set_entry+0x23f/0x472
(XEN)    [<ffff82c4801ba213>] set_p2m_entry+0x7d/0xb1
(XEN)    [<ffff82c4801ba3c9>] p2m_remove_page+0x158/0x167
(XEN)    [<ffff82c4801ba5d8>] guest_physmap_remove_page+0xd9/0x13c
(XEN)    [<ffff82c48015e0e4>] arch_memory_op+0x608/0xb3c
(XEN)    [<ffff82c4801138f3>] do_memory_op+0x1944/0x19a1
(XEN)    [<ffff82c480113b98>] do_multicall+0x248/0x390
(XEN)    [<ffff82c4801ec1bf>] syscall_enter+0xef/0x149

- The hypervisor calls domain_crash when PoD fails.
The actual console log:
(XEN) p2m_pod_demand_populate: Out of populate-on-demand memory! tot_pages 
65751 pod_entries 197408
(XEN) domain_crash called from p2m.c:1062
(XEN) Domain 1 reported crashed by domain 0 on cpu#3:
(XEN) ----[ Xen-3.5-unstable  x86_64  debug=y  Tainted:    C ]----
...[snip]
(XEN) Xen call trace:
(XEN)    [<ffff82c4801c152e>] hash_foreach+0x87/0x17e
(XEN)    [<ffff82c4801c1762>] sh_remove_all_mappings+0x13d/0x22f
(XEN)    [<ffff82c4801ca491>] shadow_write_p2m_entry+0x14f/0x390
(XEN)    [<ffff82c4801bdaf6>] p2m_set_entry+0x23f/0x472
(XEN)    [<ffff82c4801bb5b3>] set_p2m_entry+0x7d/0xb1
(XEN)    [<ffff82c4801bdf9f>] p2m_pod_zero_check+0x276/0x3d8
(XEN)    [<ffff82c4801be71f>] p2m_pod_demand_populate+0x61e/0x8dc
(XEN)    [<ffff82c4801beb5c>] p2m_pod_check_and_populate+0x17f/0x1fa
(XEN)    [<ffff82c4801bf228>] p2m_gfn_to_mfn+0x34a/0x3f3
(XEN)    [<ffff82c480166528>] mod_l1_entry+0x1aa/0x7ee
(XEN)    [<ffff82c48016774f>] do_mmu_update+0x56a/0x144b
(XEN)    [<ffff82c4801ed1bf>] syscall_enter+0xef/0x149
(XEN)
(XEN) Pagetable walk from 0000000000000000:
(XEN)  L4[0x000] = 000000011e7c4067 00000000000d9933
(XEN)  L3[0x000] = 000000011e7c3067 00000000000d9934
(XEN)  L2[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 3:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000000
(XEN) ****************************************


Signed-off-by: Kouya Shimura <kouya@xxxxxxxxxxxxxx>

diff -r c0e32941ee69 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c     Wed Nov 25 14:19:50 2009 +0000
+++ b/xen/arch/x86/mm/p2m.c     Thu Nov 26 15:56:01 2009 +0900
@@ -1221,6 +1221,12 @@ p2m_gfn_to_mfn(struct domain *d, unsigne
 
     ASSERT(paging_mode_translate(d));
 
+    if ( unlikely(d->is_dying) )
+    {
+        *t = p2m_invalid;
+        return _mfn(INVALID_MFN);
+    }
+
     /* XXX This is for compatibility with the old model, where anything not 
      * XXX marked as RAM was considered to be emulated MMIO space.
      * XXX Once we start explicitly registering MMIO regions in the p2m 
diff -r c0e32941ee69 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c   Wed Nov 25 14:19:50 2009 +0000
+++ b/xen/arch/x86/mm/shadow/common.c   Thu Nov 26 15:56:01 2009 +0900
@@ -2171,6 +2171,7 @@ static void hash_foreach(struct vcpu *v,
 
     /* Say we're here, to stop hash-lookups reordering the chains */
     ASSERT(shadow_locked_by_me(d));
+    ASSERT(d->arch.paging.shadow.hash_table);
     ASSERT(d->arch.paging.shadow.hash_walking == 0);
     d->arch.paging.shadow.hash_walking = 1;
 
@@ -3449,6 +3450,12 @@ shadow_write_p2m_entry(struct vcpu *v, u
     
     shadow_lock(d);
 
+    if ( unlikely(d->is_dying) )
+    {
+        shadow_unlock(d);
+        return;
+    }
+
     /* If we're removing an MFN from the p2m, remove it from the shadows too */
     if ( level == 1 )
     {
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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