From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: __purge_vmap_area_lazy crash with CONFIG_PREEMPT_RCU=y Date: Tue, 6 Jan 2009 17:53:29 -0200 Message-ID: <20090106195329.GB3715@amt.cnet> References: <20081210202326.GA7565@dmt.cnet> <20081230151306.GA3536@amt.cnet> <495A3F22.60509@redhat.com> <200812311332.38302.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Andrea Arcangeli , kvm-devel To: Nick Piggin Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57396 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750836AbZAFTxm (ORCPT ); Tue, 6 Jan 2009 14:53:42 -0500 Content-Disposition: inline In-Reply-To: <200812311332.38302.nickpiggin@yahoo.com.au> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Dec 31, 2008 at 01:32:37PM +1100, Nick Piggin wrote: > 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 > > >>> ---[ 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... Ok, the bug seems to be gone now. Avi, can you apply the kernel patch please? I'll send a separate patch to disable hugepage usage if mmu notifiers aren't enabled.