From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754243AbbCSPvq (ORCPT ); Thu, 19 Mar 2015 11:51:46 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53399 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751074AbbCSPvn (ORCPT ); Thu, 19 Mar 2015 11:51:43 -0400 Date: Thu, 19 Mar 2015 16:51:41 +0100 Message-ID: From: Takashi Iwai To: Andy Lutomirski Cc: Denys Vlasenko , Denys Vlasenko , Jiri Kosina , Linus Torvalds , Stefan Seyfried , X86 ML , LKML , Tejun Heo Subject: Re: PANIC: double fault, error_code: 0x0 in 4.0.0-rc3-2, kvm related? In-Reply-To: References: <5505400B.8050300@message-id.googlemail.com> <5509CBF7.3040602@message-id.googlemail.com> <5509F161.3010101@redhat.com> <550AABCB.9040502@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.4 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Thu, 19 Mar 2015 08:41:57 -0700, Andy Lutomirski wrote: > > On Thu, Mar 19, 2015 at 8:22 AM, Takashi Iwai wrote: > > At Thu, 19 Mar 2015 15:55:26 +0100, > > Takashi Iwai wrote: > >> > >> At Thu, 19 Mar 2015 14:47:12 +0100, > >> Takashi Iwai wrote: > >> > > >> > At Thu, 19 Mar 2015 13:48:56 +0100, > >> > Denys Vlasenko wrote: > >> > > > >> > > Having no more ideas at the moment, here is a tarball of 13 patches > >> > > of commits touching entry_64.S up to 4.0.0-rc1. > >> > > > >> > > x0001.patch is the latest, x0015.patch is the oldest. > >> > > > >> > > Patches 0003 and 0008 are not there since 0003 is empty merge patch > >> > > and 0008 does some PCI fixup. > >> > > > >> > > If this breakage is recent, it ought to be one of these. > >> > > Most of them do some non-trivial surgery. > >> > > > >> > > Even though I did not spot anything suspicious in them, > >> > > entry.S is notorious for subtle breakage. > >> > > > >> > > Try reverting them in sequence starting from x0001.patch > >> > > and see reverting which one makes crash disappear. > >> > > >> > OK, I'm going to check these git series. > >> > >> Reverting the commit > >> 96b6352c12711d5c0bb7157f49c92580248e8146 > >> x86_64, entry: Remove the syscall exit audit and schedule optimizations > >> > >> seems enough. After reverting this one, the machine runs stable with > >> the kvm stress test. > >> > >> (I'll keep test running for a while; at the previous bisection, I hit > >> the bug right after posting the mail ;) > > > > It survived long enough, so this looks like the spot. > > > > Also, I checked the patch below instead of reverting the commit, and > > this seems working, too. > > > > > > Takashi > > > > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S > > index 1d74d161687c..5340ac7f88a9 100644 > > --- a/arch/x86/kernel/entry_64.S > > +++ b/arch/x86/kernel/entry_64.S > > @@ -364,12 +364,12 @@ system_call_fastpath: > > * Has incomplete stack frame and undefined top of stack. > > */ > > ret_from_sys_call: > > - testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) > > - jnz int_ret_from_sys_call_fixup /* Go the the slow path */ > > - > > LOCKDEP_SYS_EXIT > > DISABLE_INTERRUPTS(CLBR_NONE) > > TRACE_IRQS_OFF > > + testl $_TIF_ALLWORK_MASK,TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) > > + jnz int_ret_from_sys_call_fixup /* Go the the slow path */ > > + > > CFI_REMEMBER_STATE > > /* > > * sysretq will re-enable interrupts: > > The crash you're seeing could certainly be caused by an IRQ at the > wrong time. However: > > int_ret_from_sys_call_fixup: > FIXUP_TOP_OF_STACK %r11, -ARGOFFSET > jmp int_ret_from_sys_call > > and > > GLOBAL(int_ret_from_sys_call) > DISABLE_INTERRUPTS(CLBR_NONE) > TRACE_IRQS_OFF > > so with or without your little patch, we're turning off IRQs very > quickly. retint_swapgs also turnes off interrupts before doing > anything. So I don't see how your patch would have any effect. What about LOCKDEP_SYS_EXIT? Takashi