On Wednesday 31 December 2008 02:32:50 Avi Kivity wrote:
> Marcelo Tosatti wrote:
> > On Tue, Dec 30, 2008 at 02:53:36PM +1100, Nick Piggin wrote:
> >>> RSP <ffff88011f4c7be8>
> >>> ---[ end trace 31811279a2e983e8 ]---
> >>> note: qemu-system-x86[4440] exited with preempt_count 2
> >>>
> >>>
> >>> (gdb) l *(__purge_vmap_area_lazy + 0x12c)
> >>> 0xffffffff80289ca2 is in __purge_vmap_area_lazy (mm/vmalloc.c:516).
> >>> 511 if (nr || force_flush)
> >>> 512 flush_tlb_kernel_range(*start, *end);
> >>> 513
> >>> 514 if (nr) {
> >>> 515 spin_lock(&vmap_area_lock);
> >>> 516 list_for_each_entry(va, &valist, purge_list)
> >>> 517 __free_vmap_area(va);
> >>> 518 spin_unlock(&vmap_area_lock);
> >>> 519 }
> >>> 520 spin_unlock(&purge_lock);
> >>>
> >>> 0xffffffff80289c9a <__purge_vmap_area_lazy+292>: mov 0x40(%rbx),%rax
> >>> 0xffffffff80289c9e <__purge_vmap_area_lazy+296>: lea
> >>> -0x40(%rax),%rbx 0xffffffff80289ca2 <__purge_vmap_area_lazy+300>:
> >>> mov 0x40(%rbx),%rax ^^^^^^^^^^^^^^^^^^^
> >
> > Note:
> >
> > RAX: 6b6b6b6b6b6b6b6b RBX: 6b6b6b6b6b6b6b2b
>
> Good old POISON_FREE.
Right, it seems like it has been kfreed while it is still accessed via RCU.
But I just can't see how the vmap_area can be freed while there is a
concurrent process traversing the vmap_area_list... __free_vmap_area removes
the entry from the list first, then does a call_rcu to kfree it.
Hmm...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
