Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2516615pxa; Mon, 17 Aug 2020 11:35:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwoRg8ibiEBSNZOYQn5IeioSUGqwbdtf1lIwhGvkWpZSn4JZ1goVFSJKkYHhsVumBOWCuR5 X-Received: by 2002:a17:906:551:: with SMTP id k17mr16245243eja.322.1597689310571; Mon, 17 Aug 2020 11:35:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597689310; cv=none; d=google.com; s=arc-20160816; b=TQsKFNBSof+QZfwRtS2Dvt4P9Y1MerwsA8QtCevdSPRHaXtMFo4xhxKt2Jy5LuOI4s cAaVW5xiTSdXGQJJcyuFpdiirZBCkFLI1HsX2h+A8awDNKbam/tJ133oGxMRHjvKcPTB R2mAxeNMb5Ewo8x4UwmdYGJXmSBGzMEiXMzTBOAV4inx/e+I938HL5AknG3Y8Rbh8DjJ u+NL1oA3+kRgUpyGCeMaM77+prpQbakD56vlgn91hPjmHkXHsRuBmEkwSLRU79Q1KXhB 6HhSmC0Rzb1nggs6NpWwpAX4t9MEeJA4agcJ4c0NpcpiHKcc88Tx/zfkWAelex9bZqjC P7Og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=1C5EnNEifoiqmf70MZjeGDRDlxFihIWRv/USflGP3cg=; b=NsWnH43aAuzEL+ByK7cGX7xzprjmjeAX+v0ljDRQ1dRc8t2XSajMxBuVCERmiCzton CTdC4/ykOe5UyClUyQCaohujJJCDbUKOXNjgCYYJIsI/TZEoC0EUZG/K/4Og8D+Jhgs+ BugX4czkKXEY7mnomWwTLpIenUTBxOpkd5l11tKlMyca+EdGBrJkpi4YqE/uLJvzeqBO zzcwDSibPghOR6SdyAeT0nl/k+xr3mTGHw0g6sn4KC4mw59YS2QUEBZ6CTzXy9hNy4iN Z9aHbgUlrnlLU23QH95fbZsX424OFmhatPwhlyuEMtv2+lNhVm1wkrarGJ1zAWurpl+r d+jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ck8si11200680edb.82.2020.08.17.11.34.47; Mon, 17 Aug 2020 11:35:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390995AbgHQSdd (ORCPT + 99 others); Mon, 17 Aug 2020 14:33:33 -0400 Received: from mga09.intel.com ([134.134.136.24]:20115 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391194AbgHQSdZ (ORCPT ); Mon, 17 Aug 2020 14:33:25 -0400 IronPort-SDR: UdlPOJnxxm+O/ZUYwfBL/z/tNYCRexoN2soL15b0jhfI8FYYQvTYrX4EZu0En96s4Nc/AI4iPb iRsWjReSWp7w== X-IronPort-AV: E=McAfee;i="6000,8403,9716"; a="155861181" X-IronPort-AV: E=Sophos;i="5.76,324,1592895600"; d="scan'208";a="155861181" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 11:33:23 -0700 IronPort-SDR: nbGYDkBru5jWL+2XrTJFOCkkUau6lpQkhmK8HLE10iRovyCehiQV4xs8wtUebHn5lBZ+ToWdbL kSFs2d1qEeog== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,324,1592895600"; d="scan'208";a="440958545" Received: from araj-mobl1.jf.intel.com ([10.254.122.10]) by orsmga004.jf.intel.com with ESMTP; 17 Aug 2020 11:33:23 -0700 Date: Mon, 17 Aug 2020 11:33:22 -0700 From: "Raj, Ashok" To: Evan Green Cc: LKML , Thomas Gleixner , Sukumar Ghorai , Srikanth Nandamuri , Mathias Nyman , Bjorn Helgaas , stable@vger.kernel.org, Ashok Raj Subject: Re: [PATCH] x86/hotplug: Silence APIC only after all irq's are migrated Message-ID: <20200817183322.GA11486@araj-mobl1.jf.intel.com> References: <20200814213842.31151-1-ashok.raj@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Evan Some details below, On Mon, Aug 17, 2020 at 11:12:17AM -0700, Evan Green wrote: > Hi Ashok, > Thank you, Srikanth, and Sukumar for some very impressive debugging here. > > On Fri, Aug 14, 2020 at 2:38 PM Ashok Raj wrote: > > > > When offlining CPU's, fixup_irqs() migrates all interrupts away from the > > outgoing CPU to an online CPU. Its always possible the device sent an > > interrupt to the previous CPU destination. Pending interrupt bit in IRR in > > lapic identifies such interrupts. apic_soft_disable() will not capture any > > new interrupts in IRR. This causes interrupts from device to be lost during > > cpu offline. The issue was found when explicitly setting MSI affinity to a > > CPU and immediately offlining it. It was simple to recreate with a USB > > ethernet device and doing I/O to it while the CPU is offlined. Lost > > interrupts happen even when Interrupt Remapping is enabled. > > > > Current code does apic_soft_disable() before migrating interrupts. > > > > native_cpu_disable() > > { > > ... > > apic_soft_disable(); > > cpu_disable_common(); > > --> fixup_irqs(); // Too late to capture anything in IRR. > > } > > > > Just fliping the above call sequence seems to hit the IRR checks > > and the lost interrupt is fixed for both legacy MSI and when > > interrupt remapping is enabled. > > > > > > Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead") > > Link: https://lore.kernel.org/lkml/875zdarr4h.fsf@nanos.tec.linutronix.de/ > > Signed-off-by: Ashok Raj > > > > To: linux-kernel@vger.kernel.org > > To: Thomas Gleixner > > Cc: Sukumar Ghorai > > Cc: Srikanth Nandamuri > > Cc: Evan Green > > Cc: Mathias Nyman > > Cc: Bjorn Helgaas > > Cc: stable@vger.kernel.org > > --- > > arch/x86/kernel/smpboot.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > > index ffbd9a3d78d8..278cc9f92f2f 100644 > > --- a/arch/x86/kernel/smpboot.c > > +++ b/arch/x86/kernel/smpboot.c > > @@ -1603,13 +1603,20 @@ int native_cpu_disable(void) > > if (ret) > > return ret; > > > > + cpu_disable_common(); > > /* > > * Disable the local APIC. Otherwise IPI broadcasts will reach > > * it. It still responds normally to INIT, NMI, SMI, and SIPI > > - * messages. > > I'm slightly unclear about whether interrupts are disabled at the core > by this point or not. I followed native_cpu_disable() up to > __cpu_disable(), up to take_cpu_down(). This is passed into a call to > stop_machine_cpuslocked(), where interrupts get disabled at the core. > So unless there's another path, it seems like interrupts are always > disabled at the core by this point. local_irq_disable() just does cli() which allows interrupts to trickle in to the IRR bits, and once you do sti() things would flow back for normal interrupt processing. > > If interrupts are always disabled, then the comment above is a little Disable interrupts is different from disabling LAPIC. Once you do the apic_soft_disable(), there is nothing flowing into the LAPIC except for INIT, NMI, SMI and SIPI messages. This turns off the pipe for all other interrupts to enter LAPIC. Which is different from doing a cli(). > obsolete, since we're not expecting to receive broadcast IPIs from > here on out anyway. We could clean up that comment in this change. > > If there is a path to here where interrupts are still enabled at the > core, then we'd need to watch out, because this change now allows > broadcast IPIs to come in during cpu_disable_common(). That could be > bad. But I think that's not this case, so this should be ok. Section SDM Vol3.b 10.4.7.2 says. * The reception of any interrupt or transmission of any IPIs that are in progress when the local APIC is disabled are completed before the local APIC enters the software-disabled state. It doesn't actually say much about broadcast IPI's, except broadcast NMI for instance, which is still permitted when cli() is set. Hope this helps. Cheers, Ashok