RE: [Xen-devel] RE: [PATCH] mem_sharing: fix race condition of nominate and unshare

[MaoXiaoyun <tinnycloud@xxxxxxxxxxx>]

Hi:
 
       More, as I previous found that, some of the nominate pages are already shared in linux HVM test.
       But it doesn't make sense.
 
       Since the in my setup, the page is allocated from  blkfront in HVM, its gref go through blktap2
and tapdisk2, it is assumed to be new, not possible has the type of shared, since if nominate failed,
the page will be filled with IO data from disk, that is to say, the page will be written again, and its previous
data is overwritten. I tested with only one HVM, it shows it has double nominate pages.
 
       I also test the windows HVM, which is no same page nominated.
       So i think it is a problem of blkfront.
 
       Am I right, could some one kindly offer some hints?
       many thanks.
 
> >>--------------------------------------------------------------------------------
> >>From: tinnycloud@xxxxxxxxxxx
> >>To: juihaochiang@xxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
> >>CC: tim.deegan@xxxxxxxxxx
> >>Subject: RE: [PATCH] mem_sharing: fix race condition of nominate and
> >> unshare
> >>Date: Tue, 18 Jan 2011 20:05:16 +0800
> >>
> >>Hi:
> >>
> >> It is later found that caused by below patch code and I am using the
> >> blktap2.
> >>The handle retruned from here will later become ch in
> >> mem_sharing_share_pages, and then
> >>in mem_sharing_share_pages will have ch = sh, thus caused the problem.
> >>
> >>+    /* Return the handle if the page is already shared */
> >>+    page = mfn_to_page(mfn);
> >>+     if (p2m_is_shared(p2mt)) {
> >>+        *phandle = page->shr_handle;
> >>+        ret = 0;
> >>+        goto out;
> >>+    }
> >>+
> >>
> >>But. after I  removed the code, tests still failed, and this handle's value
> >> is not make sence.
> >>
> >>
> >>(XEN) ===>total handles 17834 total gfns 255853
> >>(XEN) handle 13856642536914634
> >>(XEN) Debug for domain=1, gfn=19fed, Debug page: MFN=349c0a is
> >> ci=8000000000000008, ti=8400000000000007, owner_id=32755
> >>(XEN) ----[ Xen-4.0.0  x86_64  debug=n  Not tainted ]----
> >>(XEN) CPU:    15
> >>(XEN) RIP:    e008:[<ffff82c4801bff4b>]
& gt; >> mem_sharing_unshare_page+0x19b/0x720
> >>(XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor
> >>(XEN) rax: 0000000000000000   rbx: ffff83063fc67f28&nbsp ;  rcx:
> >> 0000000000000092
> >>(XEN) rdx: 000000000000000a   rsi: 000000000000000a   rdi: ffff82c48021e9c4
> >>(XEN) rbp: ffff830440000000   rsp: ffff83063fc67c48   r8:  0000000000000001
> >>(XEN) r9:  0000000000000000   r10: 00000000fffffff8   r11: 0000000000000005
> >>(XEN) r12: 0000000000019fed   r13: 0000000000000000   r14: 0000000000000000
> >>(XEN) r15: ffff82f606938140   cr0: 000000008005003b   cr4: 00000000000026f0
> >>(XEN) cr3: 000000055513c000   cr2: 0000000000000018
> >>(XEN) ds: 0000   es: 0000   fs: 0000 & nbsp; gs: 0000   ss: 0000   cs: e008
> >>(XEN) Xen stack trace from rsp=ffff83063fc67c48:
> >>(XEN)    02c5f6c8b70fed66 39ef64058b487674 ffff82c4801a6082
> >> 0000000000000000
> >>(XEN)    00313a8b00313eca 0000000000000001 0000000000000009 ff
> >> ff830440000000
> >>(XEN)    ffff83063fc67cb8 ffff82c4801df6f9 0000000000000040
> >> ffff83063fc67d04
> >>(XEN)    0000000000019fed 0000000d000001ed ffff83055458d000
> >> ffff83063fc67f28
> >>(XEN)    0000000000019fed 0000000000349c0a 0000000000000030
> >> ffff83063fc67f28
> >>(XEN)    0000000000000030 ffff82c48019baa6 ffff82c4802519c0
> >> 0000000d8016838e
> >>(XEN)    0000000000000000 00000000000001aa ffff8300bf554000
> >> ffff82c48 01b3864
> >>(XEN)    ffff830440000348 ffff8300bf554000 ffff8300bf5557f0
> >> ffff8300bf5557e8
> >>(XEN)    00000032027b81f2 ffff82c48026f080 ffff82c4801a9337
> >> ffff8300bf448000
> >>(XEN)    ffff8300bf554000 ffff830000000000 0000000019fed000
> >> ffff8300bf2f2000
> >>(XEN)    ffff82c48019985d 0000000000000080 ffff8300bf554000
> >> 0000000000019fed
> >>(XEN)    ffff82c4801b08ba 000000000001e000 ffff82c48014931f ff
> >> ff8305570c6d50
> >>(XEN)    ffff82c480251080 00000032027b81f2 ffff8305570c6d50
> >> ffff83052f3e2200
> >>(XEN)    0000000f027b7de0 ffff82c48011e07a 000000000000000f
> >> ffff82c48026f0a0
> >>(XEN)    0000000000000082 0000000000000000 0000000000000000
> >> ; 0000000000009e44
> >>(XEN)    ffff8300bf554000 ffff8300bf2f2000 ffff82c48011e07a
> >> 000000000000000f
> >>(XEN)    ffff8300bf555760 0000000000000292 ffff82c48011afca
> >> 00000032028a8fc0
> >>(XEN)    0000000000000292 ffff82c4801a93c3 00000000000000ef
> >> ffff8300bf554000
> >>(XEN)    ffff8300bf554000 ffff8300bf5557e8 ffff82c4801a6082
> >> ffff8300bf554000
> >>(XEN)    0000000000000000 ffff82c4801a0cc8 ffff8300bf554000
> >> ffff8300bf554000
> >>(XEN) Xen call trace:
> >>(XEN)    [<ffff82c4801bff4b>] mem_sharing_unshare_page+0x19b/0x720
> >>(XEN)    [<ffff82c4801a6082>] v lapic_has_pending_irq+0x42/0x70
> >>(XEN)    [<ffff82c4801df6f9>] ept_get_entry+0xa9/0x1c0
> > ;>(XEN)    [<ffff82c48019baa6>] hvm_hap_nested_page_fault+0xd6/0x190
> >>(XEN)    [<ffff82c4801b3864>] vmx_vmexit_handler+0x304/0x1a90
> >>(XEN)    [<ffff82c4801a9337>] pt_restore_timer+0x57/0xb0
> >>(XEN)    [<ffff82c48019985d>] hvm_do_resume+0x1d/0x130
> >>(XEN)    [<ffff82c4801b08ba>] vmx_do_resume+0x11a/0x1c0
> >>(XEN)    [<ffff82c48014931f>] context_switch+0x76f/0xf00
> >>(XEN)    [<ffff82c48011e07a>] add_entry+0x3a/0xb0
> >>(XEN)    [<ffff82c48011e07a>] add_entry+0x3a/0xb0
> >>(XEN)    [<ffff82c48011afca>] schedule+0x1ea/0x500
> >>(XEN)    [<ffff82c4801a93c3>] pt_update_irq+0x33/0x1e0
> >>(XEN)    [&lt ;ffff82c4801a6082>] vlapic_has_pending_irq+0x42/0x70
> >>(XEN)    [<ffff82c4801a0cc8>] hvm_vcpu_has_pending_irq+0x88/0xa0
> >>(XEN)    [<ffff82c4801b267b>] vmx_vmenter_helper+0x5b/0x150
> >>(XEN)    [<ffff82c4801adaa3>] vmx_asm_do_vmentry+0x0/0xdd
> >>(XEN)
> >>(XEN) Pagetable walk from 0000000000000018:
> >>(XEN)  L4[0x000] = 0000000000000000 ffffffffffffffff
> >>(XEN)
> >>(XEN) ****************************************
> >>(XEN) Panic on CPU 15:
> >>(XEN) FATAL PAGE FAULT
> >>(XEN) [error_code=0000]
> >>(XEN) Faulting linear address: 0000000000000018
> >>(XEN) ****************************************
> >>(XEN)
> >>(XEN) Manual reset required ('noreboot' specified)
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------------------------------------
> >>>From: tinnycloud@xxxxxxxxxxx
> >>>To: juihaochiang@xxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx
> >>>CC: tim.deegan@xxxxxxxxxx
> >>>Subject: RE: [PATCH] mem_sharing: fix race condition of nominate and
> >>> unshare
> >>>Date: Tue, 18 Jan 2011 17:42:32 +0800
> >>
> >>>Hi Tim & Jui-Hao:
> >>
> >> >     When I use Linux HVM instead of Windows HVM, more bug shows up.
> >>
> >>>      I only start on VM, and when I destroy it , xen crashed on
> >>> mem_sharing_unshare_page()
> >>>which in line709, hash_entry is NULL. Later I found the handle has been
> >>> removed in
> >>>mem_sharing_share_pag es(), please refer logs below.
> >>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
> >

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