Hi:
The latest BUG in mem_sharing_alloc_page from mem_sharing_unshare_page.
I printed heap info, which shows plenty memory left.
Could domain be NULL during in unshare, or should it be locked by rcu_lock_domain_by_id ?
-----------code------------
422 extern void pagealloc_info(unsigned char key);
423 static struct page_info* mem_sharing_alloc_page(struct domain *d,
424 unsigned long gfn,
425 int must_succeed)
426 {
427 struct page_info* page;
428 struct vcpu *v = current;
429 mem_event_request_t req;
430
&n
bsp;431 page = alloc_domheap_page(d, 0);
432 if(page != NULL) return page;
433
434 memset(&req, 0, sizeof(req));
435 if(must_succeed)
436 {
437 /* We do not support 'must_succeed' any more. External operations such
438 * as grant table mappings may fail with OOM condition!
439 */
440 pagealloc_info('m');
441 BUG();
442 }
-------------serial output-------
(XEN) Physical memory information:
(XEN) Xen heap: 0kB free
(XEN) heap[14]: 64480kB free
(XEN) heap[15]: 131072kB free
(XEN) heap[16]: 262144kB free
(XEN) heap[17]: 524288kB free
(XEN) heap[18]: 1048576kB free
(XEN) heap[19]: 1037128kB free
(XEN) heap[20]: 3035744kB free
(XEN) heap[21]: 2610292kB free
(XEN) heap[22]: 2866212kB free
(XEN) Dom heap: 11579936kB free
(XEN) Xen BUG at mem_sharing.c:441
(XEN) ----[ Xen-4.0.0 x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82c4801c0531>] mem_sharing_unshare_page+0x681/0x790
(XEN) RFLAGS: 0000000000010282 CONTEXT: hypervisor
(XEN) rax
: 0000000000000000 rbx: ffff83040092d808 rcx: 0000000000000096
(XEN) rdx: 000000000000000a rsi: 000000000000000a rdi: ffff82c48021eac4
(XEN) rbp: 0000000000000000 rsp: ffff82c48035f5e8 r8: 0000000000000001
(XEN) r9: 0000000000000001 r10: 00000000fffffff5 r11: 0000000000000008
(XEN) r12: ffff8305c61f3980 r13: ffff83040eff0000 r14: 000000000001610f
(XEN) r15: ffff82c48035f628 cr0: 000000008005003b cr4: 00000000000026f0
(XEN) cr3: 000000052bc4f000 cr2: ffff880120126e88
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008
(XEN) Xen stack trace from rsp=ffff82c48035f5e8:
(XEN) ffff8305c61f3990 00018300bf2f0000 ffff82f604e6a4a0 000000002ab84078
(XEN) ffff83040092d7f0 00000000001b9c9c ff
ff8300bf2f0000 000000010eff0000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000d0000010f ffff8305447ec000 000000000001610f
(XEN) 0000000000273525 ffff82c48035f724 ffff830502c705a0 ffff82f602c89a00
(XEN) ffff83040eff0000 ffff82c48010bfa9 ffff830572c5dbf0 000000000029e07f
(XEN) 0000000000000000 ffff830572c5dbf0 000000008035fbe8 ffff82c48035f6f8
(XEN) 0000000100000002 ffff830572c5dbf0 ffff83063fc30000 ffff830572c5dbf0
(XEN) 0000035900000000 ffff88010d14bbe0 ffff880159e09000 00003f7e00000002
(XEN) ffffffffffff0032 ffff88010d14bbb0 ffff830438dfa920 0000000d8010a650
(XEN) 0000000000000100 ffff83063fc30000 ffff8305f9203730 ffffffffffffffea
(XEN) ffff88010d14bb70 0000000000000000 ffff88010d14bc10 ffff88010d14bbc0
(XEN)
0000000000000002 ffff82c48010da9b 0000000000000202 ffff82c48035fec8
(XEN) ffff82c48035f7c8 00000000801880af ffff83063fc30010 0000000000000000
(XEN) ffff82c400000008 ffff82c48035ff28 0000000000000000 ffff88010d14bbc0
(XEN) ffff880159e08000 0000000000000000 0000000000000000 00020000000002d7
(XEN) 00000000003f2b38 ffff8305b1f4b6b8 ffff8305b30f0000 ffff880159e09000
(XEN) 0000000000000000 0000000000000000 000200000000008a 00000000003ed1f9
(XEN) ffff83063fc26450 ffff8305b30f0000 ffff880159e0a000 0000000000000000
(XEN) 0000000000000000 00020000000001fa 000000000029e2ba ffff83063fc26fd0
(XEN) Xen call trace:
(XEN) [<ffff82c4801c0531>] mem_sharing_unshare_page+0x681/0x790
(XEN) [<ffff82c48010bfa9>] gnttab_map_grant_ref+0xbf9/0xe30
(XEN) [<fff
f82c48010da9b>] do_grant_table_op+0x14b/0x1080
(XEN) [<ffff82c48010fb44>] do_xen_version+0xb4/0x480
(XEN) [<ffff82c4801b8215>] set_p2m_entry+0x85/0xc0
(XEN) [<ffff82c4801bc92e>] set_shared_p2m_entry+0x1be/0x2f0
(XEN) [<ffff82c480121c4c>] xmem_pool_free+0x2c/0x310
(XEN) [<ffff82c4801bfaf8>] mem_sharing_share_pages+0xd8/0x3d0
(XEN) [<ffff82c4801447da>] __find_next_bit+0x6a/0x70
(XEN) [<ffff82c48011c519>] cpumask_raise_softirq+0x89/0xa0
(XEN) [<ffff82c480118351>] csched_vcpu_wake+0x101/0x1b0
(XEN) [<ffff82c48014717d>] vcpu_kick+0x1d/0x80
(XEN) [<ffff82c4801447da>] __find_next_bit+0x6a/0x70
(XEN) [<ffff82c48015a1d8>] get_page+0x28/0xf0
(XEN) [<ffff82c48015ed72&g
t;] do_update_descriptor+0x1d2/0x210
(XEN) [<ffff82c480113d7e>] do_multicall+0x14e/0x340
(XEN) [<ffff82c4801e3169>] syscall_enter+0xa9/0xae
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at mem_sharing.c:441
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
> Date: Mon, 17 Jan 2011 17:02:02 +0800
> Subject: Re: [PATCH] mem_sharing: fix race condition of nominate and unshare
> From: juihaochiang@xxxxxxxxx
> To: tinnycloud@xxxxxxxxxxx
> CC: xen-devel@xxxxxxxxxxxxxxxxxxx; tim.deegan@xxxxxxxxxx
>
> Hi, tinnycloud:
>
> Do you have xenpaging tools running properly?
> I haven't gone through that one, but it seems you have run out of memory.
> When this case happens, mem_sharing will request memory to the
> xenpaging daemon, which tends to page out and free some memory.
> Otherwise, the allocation would fail.
> Is this your scenario?
>
> Bests,
> Jui-Hao
>
> 2011/1/17 MaoXiaoyun <tinnycloud@xxxxxxxxxxx>:
> > Another failure on BUG() in mem_sharing_alloc_page()
> >
> > memset(&req, 0, sizeof(req));
> > if(must_succeed)
> > {
> &g
t; /* We do not support 'must_succeed' any more. External operations
> > such
> > * as grant table mappings may fail with OOM condition!
> > */
> > BUG();===================>bug here
> > }
> > else
> > {
> > /* All foreign attempts to unshare pages should be handled through
> > * 'must_succeed' case. */
> > ASSERT(v->domain->domain_id == d->domain_id);
> > vcpu_pause_nosync(v);
> > req.flags |= MEM_EVENT_
FLAG_VCPU_PAUSED;
> > }
> >
|
