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

Re: [Xen-devel] vfree crash



> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Petre 
> Ovidiu PIRCALABU
> Sent: 28 June 2019 19:00
> To: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
> Cc: Alexandru Stefan ISAILA <aisaila@xxxxxxxxxxxxxxx>; 
> rcojocaru@xxxxxxxxxxxxxxx
> Subject: [Xen-devel] vfree crash
> 
> Hello,
> 
> I need your help to pinpoint the root cause of a problem. To my
> understanding vfree should be used when allocating memory with vmalloc.
> 
> But, I have the following scenario which results in a XEN crash:
> - allocate a number of frames using vmalloc (vzalloc) (e.g. using a
> domctl) and assign them to the calling domain
> - map the frames using xenforeignmemory_map_resource

Do you really mean xenforeignmemory_map_resource()? If the memory is assigned 
to the calling domain then this is quite likely not to work. There were 
reference counting problems with that code, which is why caller assigned 
resources were dropped.

  Paul

> ....
> - xenforeignmemory_unmap_resource
> - vfree.
> 
> (XEN) ----[ Xen-4.13-unstable  x86_64  debug=y   Tainted:  C   ]----
> (XEN) CPU:    6
> (XEN) RIP:    e008:[<ffff82d08022618d>] free_domheap_pages+0x2d0/0x40d
> (XEN) RFLAGS: 0000000000010246   CONTEXT: hypervisor (d0v3)
> (XEN) rax: ffff82e00bf6ee00   rbx: ffff830806584000   rcx:
> ffff82ffffffffe0
> (XEN) rdx: ffff82ffffffffe0   rsi: 0000000000000000   rdi:
> ffff830806584028
> (XEN) rbp: ffff8308065a7c78   rsp:
> ffff8308065a7c38   r8:  00000000ffffffff
> (XEN) r9:  0000000000000001   r10: ffff82e000000000   r11:
> 4000000000000000
> (XEN) r12: ffff82e00bf6ee00   r13: ffff830806584028   r14:
> ffff830806584038
> (XEN) r15: 00ffffffffffffff   cr0: 0000000080050033   cr4:
> 0000000000362660
> (XEN) cr3: 00000005fb565000   cr2: ffff82ffffffffe0
> (XEN) fsb: 00007f1265e36700   gsb: ffff8882168c0000   gss:
> 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen code around <ffff82d08022618d>
> (free_domheap_pages+0x2d0/0x40d):
> (XEN)  47 08 0f 85 0f 01 00 00 <c7> 02 ff ff ff ff 48 89 57 08 eb 4b 48
> 39 83 30
> (XEN) Xen stack trace from rsp=ffff8308065a7c38:
> (XEN)    ffff830806584020 0000000000000001 ffff8308065a7c78
> ffff82e00bf6ee00
> (XEN)    0000000000000000 ffff82e000000000 0000000000000001
> 000ffffffffff000
> (XEN)    ffff8308065a7cd8 ffff82d08024323f 0000000000000000
> ffff82c000267000
> (XEN)    0000000000000000 00000001065a7ca8 8086000000008086
> ffff8305f822bfe0
> (XEN)    ffff8305fd17a000 00007f1265e53010 ffff8305fd17a000
> 0000000000000000
> (XEN)    ffff8308065a7d28 ffff82d0802484fc ffff8305fd17a000
> 0000000000000000
> (XEN)    0000000000000292 0000000000000000 ffff8305fd17a000
> 00007f1265e53010
> (XEN)    ffff82d08020550f 0000000000000000 ffff8308065a7e48
> ffff82d080206c2c
> (XEN)    0000000000000003 00007f1265e52000 80000005fb770327
> 00007f1265e52000
> (XEN)    ffff830806559000 ffff830806584000 ffff830806584000
> 0000000000000001
> (XEN)    ffff8308065a7d88 ffff82d0802861cd 0000001100000053
> 0000000000000001
> (XEN)    0000000000000001 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 09fab73a51d28500
> (XEN)    ffff82d0803803d4 ffff8308065a7ef8 ffff830806559000
> 0000000000000024
> (XEN)    ffff82d08020550f 0000000000000001 ffff8308065a7ee8
> ffff82d080379fb7
> (XEN)    00007f1265e53010 deadbeefdeadf00d deadbeefdeadf00d
> deadbeefdeadf00d
> (XEN)    deadbeefdeadf00d deadbeefdeadf00d ffff82d0803803d4
> ffff82d0803803c8
> (XEN)    ffff82d0803803d4 ffff82d0803803c8 ffff82d0803803d4
> ffff82d0803803c8
> (XEN) Xen call trace:
> (XEN)    [<ffff82d08022618d>] free_domheap_pages+0x2d0/0x40d
> (XEN)    [<ffff82d08024323f>] vfree+0x126/0x159
> (XEN)    [<ffff82d0802484fc>] mock_domctl+0x177/0x19e
> (XEN)    [<ffff82d080206c2c>] do_domctl+0x171d/0x1beb
> (XEN)    [<ffff82d080379fb7>] pv_hypercall+0x2aa/0x521
> (XEN)    [<ffff82d080380432>] lstar_enter+0x112/0x120
> (XEN)
> (XEN) Pagetable walk from ffff82ffffffffe0:
> (XEN)  L4[0x105] = 00000000dd28e063 ffffffffffffffff
> (XEN)  L3[0x1ff] = 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 6:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=0002]
> (XEN) Faulting linear address: ffff82ffffffffe0
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> (XEN) APIC error on CPU0: 40(00)
> 
> The crash happens when page_list_del2 is called (arch_free_heap_page(d,
> &pg[i])). This in turn calls __page_list_del_head and is caused by the
> "prev->list.next = PAGE_LIST_NULL;" statement (head->tail == page)
> 
> The problem is strictly related to vfree because if I call vunmap and
> free_domheap_page manually, the crash doesn't occur anymore.
> 
> Unfortunately I have no ideea what might cause this.
> 
> I have pushed a small test which triggers this crash at
> https://github.com/petrepircalabu/xen/tree/vfree_crash and I would
> greatly appreciate your input.
> 
> Many thanks for your support,
> Petre
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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