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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F1D7C77B7E for ; Tue, 2 May 2023 10:30:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233774AbjEBKad (ORCPT ); Tue, 2 May 2023 06:30:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233864AbjEBK3Z (ORCPT ); Tue, 2 May 2023 06:29:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 374AA5FC8 for ; Tue, 2 May 2023 03:28:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8C6BF61EBA for ; Tue, 2 May 2023 10:28:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB4AAC433EF; Tue, 2 May 2023 10:28:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683023318; bh=ICdHmHkqIvGRRD92AKqXdsbOz7Gc1Fats03WPwlJmPY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RtkyytQK1Gu1sNgCWib48B5aAeBI9Ga+3aqkoSKa/pf/H2i7mVZt0Myvhw0Jrdfuf 6K7rsIl2+Nur5WytryPDf/ooMdDqme34UvDKac91bt3xaHhHZcLB42f4nqfjoyhzFb XnH7wySGj0TJcTsA5YGSieThblVJpf67LsyJxWT7VbbwSAoBPgnv5W/f4HXCfg/yCK R+wdL7IkqDRR7ZCossy2OyH+6lzOrpIpt3pog/KMctPyo09AnXDdAqXD6zIWr0ROk5 V8S2l7hw7oKGOz3xBKMLg/u0SjRFg/5Mdvw7O8fimb2w/UzMcseHQs7OFUNbSkKQz3 VOaeCS9/4BPlw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ptnFL-00CSOi-IM; Tue, 02 May 2023 11:28:35 +0100 Date: Tue, 02 May 2023 11:28:35 +0100 Message-ID: <86r0rzgh7w.wl-maz@kernel.org> From: Marc Zyngier To: "Gowans, James" Cc: "tglx@linutronix.de" , "Raslan, KarimAllah" , "Woodhouse, David" , "zouyipeng@huawei.com" , "linux-kernel@vger.kernel.org" , "Sironi, Filippo" , "chris.zjh@huawei.com" Subject: Re: [PATCH] irq: fasteoi handler re-runs on concurrent invoke In-Reply-To: <7fdfb01590d8e502f384aa0bb0dc9c614caa5dfc.camel@amazon.com> References: <20230317095300.4076497-1-jgowans@amazon.com> <87h6tp5lkt.wl-maz@kernel.org> <0869847124f982c50d0f8d0ede996004f90a5576.camel@amazon.com> <86pm89kyyt.wl-maz@kernel.org> <7fdfb01590d8e502f384aa0bb0dc9c614caa5dfc.camel@amazon.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jgowans@amazon.com, tglx@linutronix.de, karahmed@amazon.com, dwmw@amazon.co.uk, zouyipeng@huawei.com, linux-kernel@vger.kernel.org, sironi@amazon.de, chris.zjh@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Catching up... On Tue, 18 Apr 2023 11:56:07 +0100, "Gowans, James" wrote: > > On Wed, 2023-04-12 at 14:32 +0100, Marc Zyngier wrote: > > > > From c96d2ab37fe273724f1264fba5f4913259875d56 Mon Sep 17 00:00:00 2001 > > From: Marc Zyngier > > Date: Mon, 10 Apr 2023 10:56:32 +0100 > > Subject: [PATCH] irqchip/gicv3-its: Force resend of LPIs taken while > > already > > in-progress > > Perhaps you can pillage some of my commit message to explain the race here > when you send this patch? Sure. At the moment, we're still far from a final patch though. > > > > Signed-off-by: Marc Zyngier > > > > diff --git a/include/linux/irq.h b/include/linux/irq.h > > index b1b28affb32a..4b2a7cc96eb2 100644 > > --- a/include/linux/irq.h > > +++ b/include/linux/irq.h > > @@ -223,6 +223,8 @@ struct irq_data { > > * irq_chip::irq_set_affinity() when > > deactivated. > > * IRQD_IRQ_ENABLED_ON_SUSPEND - Interrupt is enabled on suspend by irq > > pm if > > * irqchip have flag > > IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND set. > > + * IRQD_RESEND_WHEN_IN_PROGRESS - Interrupt may fire when already in > > progress, > > + * needs resending. > > */ > > enum { > > IRQD_TRIGGER_MASK = 0xf, > > @@ -249,6 +251,7 @@ enum { > > IRQD_HANDLE_ENFORCE_IRQCTX = (1 << 28), > > IRQD_AFFINITY_ON_ACTIVATE = (1 << 29), > > IRQD_IRQ_ENABLED_ON_SUSPEND = (1 << 30), > > + IRQD_RESEND_WHEN_IN_PROGRESS = (1 << 31), > > }; > > Do we really want a new flag here? I'd be keen to fix this race for all > drivers, not just those who know to set this flag. I think the patch > you're suggesting is pretty close to being safe to enable generally? If so > my preference is for one less config option - just run it always. I contend that this really is a GICv3 architectural bug. The lack of an active state on LPIs leads to it, and as far as I can tell, no other interrupt architecture has the same issue. So the onus should be on the GIC, the GIC only, and only the parts of the GIC that require it (SPIs, PPIs and SGIs are fine, either because they have an active state, or because the lock isn't dropped when calling the handler). Thanks, M. -- Without deviation from the norm, progress is not possible.