From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C39B2C76186 for ; Thu, 18 Jul 2019 03:24:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9CF7820818 for ; Thu, 18 Jul 2019 03:24:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563420292; bh=5La0qRrvICGFYOZh00pZoEO9HCwNjut63ExzoTxuqwA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=VjsYsCFGTGgT7IWGPCjN4oLbpltcb6pl2HL4VmugFZXuikVESz+MGiZp5t3mzfCgL nKhSzkwWDJHd3gmGypQpwGVDXBI4nyRMvzSUcqKs3pG4HcDsxepZxOpNmM49fDvhzZ 5CpgCgAV0R9levhp5WyGzhk3F+Gom+S3xqiZARtc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389544AbfGRDGT (ORCPT ); Wed, 17 Jul 2019 23:06:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:37456 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390180AbfGRDGP (ORCPT ); Wed, 17 Jul 2019 23:06:15 -0400 Received: from localhost (115.42.148.210.bf.2iij.net [210.148.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 047D22173E; Thu, 18 Jul 2019 03:06:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563419174; bh=5La0qRrvICGFYOZh00pZoEO9HCwNjut63ExzoTxuqwA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IdzEKEdK4F9jg5P0703d6Yxdm1JMZX8m0TsCLMZJjoLaH9YXHpM/Kpz0Gcr9mRtXe qn1GpR4YglzkJ4gz6JoQezI5eHZhPmraUQg4BZA3UnMBook8PAf0UbS2NQ7uEU0mwL gbQWq3lwEcjlgxrEZ3UT1IBE3iRH1TXlrh82Y06A= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robert Hodaszi , Marc Zyngier , Thomas Gleixner Subject: [PATCH 5.1 45/54] x86/irq: Handle spurious interrupt after shutdown gracefully Date: Thu, 18 Jul 2019 12:01:40 +0900 Message-Id: <20190718030056.656558427@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190718030053.287374640@linuxfoundation.org> References: <20190718030053.287374640@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Thomas Gleixner commit b7107a67f0d125459fe41f86e8079afd1a5e0b15 upstream. Since the rework of the vector management, warnings about spurious interrupts have been reported. Robert provided some more information and did an initial analysis. The following situation leads to these warnings: CPU 0 CPU 1 IO_APIC interrupt is raised sent to CPU1 Unable to handle immediately (interrupts off, deep idle delay) mask() ... free() shutdown() synchronize_irq() clear_vector() do_IRQ() -> vector is clear Before the rework the vector entries of legacy interrupts were statically assigned and occupied precious vector space while most of them were unused. Due to that the above situation was handled silently because the vector was handled and the core handler of the assigned interrupt descriptor noticed that it is shut down and returned. While this has been usually observed with legacy interrupts, this situation is not limited to them. Any other interrupt source, e.g. MSI, can cause the same issue. After adding proper synchronization for level triggered interrupts, this can only happen for edge triggered interrupts where the IO-APIC obviously cannot provide information about interrupts in flight. While the spurious warning is actually harmless in this case it worries users and driver developers. Handle it gracefully by marking the vector entry as VECTOR_SHUTDOWN instead of VECTOR_UNUSED when the vector is freed up. If that above late handling happens the spurious detector will not complain and switch the entry to VECTOR_UNUSED. Any subsequent spurious interrupt on that line will trigger the spurious warning as before. Fixes: 464d12309e1b ("x86/vector: Switch IOAPIC to global reservation mode") Reported-by: Robert Hodaszi Signed-off-by: Thomas Gleixner - Tested-by: Robert Hodaszi Cc: Marc Zyngier Link: https://lkml.kernel.org/r/20190628111440.459647741@linutronix.de Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/hw_irq.h | 3 ++- arch/x86/kernel/apic/vector.c | 4 ++-- arch/x86/kernel/irq.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/hw_irq.h +++ b/arch/x86/include/asm/hw_irq.h @@ -151,7 +151,8 @@ extern char irq_entries_start[]; #endif #define VECTOR_UNUSED NULL -#define VECTOR_RETRIGGERED ((void *)~0UL) +#define VECTOR_SHUTDOWN ((void *)~0UL) +#define VECTOR_RETRIGGERED ((void *)~1UL) typedef struct irq_desc* vector_irq_t[NR_VECTORS]; DECLARE_PER_CPU(vector_irq_t, vector_irq); --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -343,7 +343,7 @@ static void clear_irq_vector(struct irq_ trace_vector_clear(irqd->irq, vector, apicd->cpu, apicd->prev_vector, apicd->prev_cpu); - per_cpu(vector_irq, apicd->cpu)[vector] = VECTOR_UNUSED; + per_cpu(vector_irq, apicd->cpu)[vector] = VECTOR_SHUTDOWN; irq_matrix_free(vector_matrix, apicd->cpu, vector, managed); apicd->vector = 0; @@ -352,7 +352,7 @@ static void clear_irq_vector(struct irq_ if (!vector) return; - per_cpu(vector_irq, apicd->prev_cpu)[vector] = VECTOR_UNUSED; + per_cpu(vector_irq, apicd->prev_cpu)[vector] = VECTOR_SHUTDOWN; irq_matrix_free(vector_matrix, apicd->prev_cpu, vector, managed); apicd->prev_vector = 0; apicd->move_in_progress = 0; --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -246,7 +246,7 @@ __visible unsigned int __irq_entry do_IR if (!handle_irq(desc, regs)) { ack_APIC_irq(); - if (desc != VECTOR_RETRIGGERED) { + if (desc != VECTOR_RETRIGGERED && desc != VECTOR_SHUTDOWN) { pr_emerg_ratelimited("%s: %d.%d No irq handler for vector\n", __func__, smp_processor_id(), vector);