From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= Subject: Re: Xen-unstable, stubdom causes hypervisor crash Date: Wed, 20 May 2015 18:04:03 +0200 Message-ID: <555CB073.3040705@citrix.com> References: <20150520153952.GC23128@zion.uk.xensource.com> <555CABBF.1040204@citrix.com> <555CAC15.5000405@citrix.com> <555CCB8B020000780007C5A7@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yv6dh-0002qm-8C for xen-devel@lists.xenproject.org; Wed, 20 May 2015 16:14:37 +0000 In-Reply-To: <555CCB8B020000780007C5A7@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Andrew Cooper , Wei Liu Cc: xen-devel@lists.xenproject.org, tim@xen.org List-Id: xen-devel@lists.xenproject.org El 20/05/15 a les 17.59, Jan Beulich ha escrit: >>>> On 20.05.15 at 17:45, wrote: >> On 20/05/15 16:43, Andrew Cooper wrote: >>> On 20/05/15 16:39, Wei Liu wrote: >>>> I discovered this when running qemu-trad stubdom + shadow page table. >>>> >>>> (XEN) Assertion 'pages' failed at vmap.c:275 >>>> (XEN) ----[ Xen-4.6-unstable x86_64 debug=3Dy Tainted: C ]---- >>>> (XEN) CPU: 1 >>>> (XEN) RIP: e008:[] vfree+0x1e/0x128 >>>> (XEN) RFLAGS: 0000000000010246 CONTEXT: hypervisor (d2v0) >>>> (XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx: ffff82c0001= fff66 >>>> (XEN) rdx: 0000000000000000 rsi: 0000000000009bd1 rdi: 00000000000= 00000 >>>> (XEN) rbp: ffff830224857cc8 rsp: ffff830224857c88 r8: ffff8302248= 57ca4 >>>> (XEN) r9: 0000000000000000 r10: ffff82d080261e40 r11: 00000000000= 00202 >>>> (XEN) r12: 0000000000000000 r13: ffff830215672000 r14: 00000000000= 00000 >>>> (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000= 026f4 >>>> (XEN) cr3: 00000001cb060000 cr2: ffff880012dbd6c8 >>>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 >>>> (XEN) Xen stack trace from rsp=3Dffff830224857c88: >>>> (XEN) 0000000000000000 ffff830224857ca8 ffff82d08012f5c6 0000000000= 000000 >>>> (XEN) 0000000000000000 ffff830215672000 0000000000000000 0000000000= 000000 >>>> (XEN) ffff830224857d78 ffff82d08021c4ad 0000000000000200 0000000000= 000005 >>>> (XEN) ffff830224857d58 ffff82d0801620ca ffff830224886020 0000000000= 000000 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000= 000000 >>>> (XEN) ffff830215672ac0 0000000000000000 0000000000000006 0000002002= 00b004 >>>> (XEN) ffffffffffffffea ffffffffffffffff 0000000000000006 0000002002= 00b004 >>>> (XEN) ffffffffffffffea 0000000000000000 ffff830224857e58 ffff82d080= 1d4ae0 >>>> (XEN) 0000000000000000 0000000000000000 0000000000000001 0000000000= 000000 >>>> (XEN) ffff830224857db8 ffff830224857dc8 0000000000000202 ffff830224= 857dd8 >>>> (XEN) ffff830224857dd8 ffff82d08019e6eb ffff830224857e28 ffff82d080= 19ed8a >>>> (XEN) ffff83020180a0c8 00000000000ee6c7 ffff830224857e28 ffff830215= 672000 >>>> (XEN) 0000000000000001 0000000000000000 0000000000000000 0000000000= 000000 >>>> (XEN) ffff830224857f08 ffff8300cf0fc1f8 ffff8300cf0fc000 0000000000= 5ef640 >>>> (XEN) ffff830224850000 0000000000000000 ffff830224857ef8 ffff82d080= 11bb5f >>>> (XEN) ffff8300cf0fc200 ffff8300cf0fc208 0000000100000000 ffff8300cf= 0fc1f8 >>>> (XEN) ffff830224857ea8 ffff82d000a0fb00 0000000000000000 ffffffffff= ffffff >>>> (XEN) ffff830224857ec8 ffff82d000000031 ffff82d080320000 ffff82d080= 31ff80 >>>> (XEN) ffff830224857ef8 ffff8300cf0fc000 00000000005ef640 0000002002= 02e1f0 >>>> (XEN) 0000000000000001 000000200201ba18 00007cfddb7a80c7 ffff82d080= 247bdb >>>> (XEN) Xen call trace: >>>> (XEN) [] vfree+0x1e/0x128 >>>> (XEN) [] shadow_track_dirty_vram+0x7ca/0x8aa >>>> (XEN) [] do_hvm_op+0x1aec/0x273b >>>> (XEN) [] do_multicall+0x257/0x3dc >>>> (XEN) [] syscall_enter+0xeb/0x145 >>>> (XEN) >>>> (XEN) >>>> (XEN) **************************************** >>>> (XEN) Panic on CPU 1: >>>> (XEN) Assertion 'pages' failed at vmap.c:275 >>>> (XEN) **************************************** >>>> (XEN) >>>> >>>> Any idea what might go wrong? >>> I have an idea - patch incoming >> >> Try this: It appears that vfree(NULL) isn't safe. > = > And intentionally so (I think this was even mentioned while discussing > the patch), matching vunmap(). Yes, but previous versions of vfree where able to cope with NULL. The = following fixes the callers: Signed-off-by: Roger Pau Monn=E9 --- diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c index cea7990..0316b59 100644 --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -174,7 +174,8 @@ int hap_track_dirty_vram(struct domain *d, p2m_ram_logdirty, p2m_ram_rw); } out: - vfree(dirty_bitmap); + if ( dirty_bitmap ) + vfree(dirty_bitmap); = return rc; } diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/commo= n.c index 9e9d19f..88e0f7e 100644 --- a/xen/arch/x86/mm/shadow/common.c +++ b/xen/arch/x86/mm/shadow/common.c @@ -3707,7 +3707,8 @@ out: paging_unlock(d); rc =3D -EFAULT; } - vfree(dirty_bitmap); + if ( dirty_bitmap ) + vfree(dirty_bitmap); p2m_unlock(p2m_get_hostp2m(d)); return rc; }