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, 30 Dec 2008 13:13:06 -0200 Message-ID: <20081230151306.GA3536@amt.cnet> References: <20081210202326.GA7565@dmt.cnet> <20081224152844.GE29319@random.random> <20081229145821.GA3823@amt.cnet> <200812301453.37230.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrea Arcangeli , Avi Kivity , kvm-devel To: Nick Piggin Return-path: Received: from mx2.redhat.com ([66.187.237.31]:34898 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752182AbYL3PNR (ORCPT ); Tue, 30 Dec 2008 10:13:17 -0500 Content-Disposition: inline In-Reply-To: <200812301453.37230.nickpiggin@yahoo.com.au> Sender: kvm-owner@vger.kernel.org List-ID: 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 > > 0xffffffff80289ca6 <__purge_vmap_area_lazy+304>: prefetcht0 (%rax) > > > > > > Which vanishes once PREEMPT_RCU is disabled. > > > > Nick? KVM does not make direct use of RCU. Same issue happens if the > > entire __purge_vmap_area_lazy runs with vmap_area_lock held. Hum, mmu_notifiers does. > The thing is that the valist and va->purge_list is protected by > purge_lock in that function. Which disables preemption... > I can't easily see how that could get corrupted. Perhaps the corruption happens before the freeing pass. > Is it easy to reproduce? Yes. Enable CONFIG_PREEMPT, CONFIG_PREEMPT_RCU, and DEBUG_PREEMPT. Start a Linux guest, wait for boot to finish, and shut it down. Sometimes it happens even before guest shutdown, in the complete_pio path as reported. > Can you try putting preempt_disable around rcu_read_lock? Tried it before, does not help. Even tried to protect all rcu_read_lock/unlock pairs with preempt_disable/enable in vmalloc.c.