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=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BC914C433DF for ; Thu, 30 Jul 2020 18:12:27 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8E0D020829 for ; Thu, 30 Jul 2020 18:12:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="p+j2YIVV"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="fl299ZqP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E0D020829 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fmKDRJFhAHlaPDTVXOtQjNrxhTOBchLviJKdcAzs9nI=; b=p+j2YIVV5kxF1FpqemUN5Glwm Fu8s+Qx2/FWpyJtoMiRxKsjLt/H7WsqGWS3p3oneKC6cO+lSvtrHKkXxNYkrhByNoZyMWuSqeTaXn qVm3207ytx9HSg/ipT0EC9vaPZhbPgp2ZlMJ7dX4Ck+qv54hlnSakMtCdgWaj3bmRs5DZ5ivjj9dE f/ld5h03kfGN1Qijr9skAHDPnPyqH3u5lxA4bSjg/MDxUpmsjELDHT4uW1tlTsRELq8pu2FRvRQVm quu5A0Zk9moCUgDrgNCvgtR+RYJPIKUvaTYDJoIoFaLGhGwlgxRBz/4CzcmU47GpbrrNUnaRYieMO +xeE3Rgtg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1D10-0007lD-0s; Thu, 30 Jul 2020 18:10:50 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1D0w-0007ki-S4 for linux-arm-kernel@lists.infradead.org; Thu, 30 Jul 2020 18:10:47 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 1843D20829; Thu, 30 Jul 2020 18:10:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596132646; bh=oy4zBu3xLBCuWxdfRxweVj3pqrgDJqo/r08Kl3Db94g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fl299ZqPsQzWw9UVgzFctl4++/RwzhtHSmL+sPpgHZLcjvSdE26MKYvDtoNPvtCKP mo/1w6qj8PpE0ErMIE2Aw2XcRgsnE0h/LePYRHTcoQ/MjvjdII7TpzUHWU8busK7zV /ze1wpqbNMVAZ7q9TAzIrB4CXKwS9+P9AlpDj9hY= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k1D0u-00GKY3-DU; Thu, 30 Jul 2020 19:10:44 +0100 MIME-Version: 1.0 Date: Thu, 30 Jul 2020 19:10:44 +0100 From: Marc Zyngier To: Valentin Schneider Subject: Re: [PATCH v2 2/2] irqchip/gic-v2, v3: Prevent SW resends entirely In-Reply-To: <20200730170321.31228-3-valentin.schneider@arm.com> References: <20200730170321.31228-1-valentin.schneider@arm.com> <20200730170321.31228-3-valentin.schneider@arm.com> User-Agent: Roundcube Webmail/1.4.5 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, jason@lakedaemon.net, Lorenzo.Pieralisi@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200730_141047_117483_2366A850 X-CRM114-Status: GOOD ( 26.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Gleixner , Lorenzo Pieralisi , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jason Cooper Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Valentin, On 2020-07-30 18:03, Valentin Schneider wrote: > The GIC irqchips can now use a HW resend when a retrigger is invoked by > check_irq_resend(). However, should the HW resend fail, > check_irq_resend() > will still attempt to trigger a SW resend, which is still a bad idea > for > the GICs. > > Prevent this from happening by setting IRQD_HANDLE_ENFORCE_IRQCTX on > all > GIC IRQs. Technically per-cpu IRQs do not need this, as their flow > handlers > never set IRQS_PENDING, but this aligns all IRQs wrt context > enforcement: > this also forces all GIC IRQ handling to happen in IRQ context (as > defined > by in_irq()). > > Signed-off-by: Valentin Schneider > --- > drivers/irqchip/irq-gic-v3.c | 5 ++++- > drivers/irqchip/irq-gic.c | 6 +++++- > 2 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3.c > b/drivers/irqchip/irq-gic-v3.c > index 0fbcbf55ec48..1a8acf7cd8ac 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -1279,6 +1279,7 @@ static int gic_irq_domain_map(struct irq_domain > *d, unsigned int irq, > irq_hw_number_t hw) > { > struct irq_chip *chip = &gic_chip; > + struct irq_data *irqd = irq_desc_get_irq_data(irq_to_desc(irq)); > > if (static_branch_likely(&supports_deactivate_key)) > chip = &gic_eoimode1_chip; > @@ -1296,7 +1297,7 @@ static int gic_irq_domain_map(struct irq_domain > *d, unsigned int irq, > irq_domain_set_info(d, irq, hw, chip, d->host_data, > handle_fasteoi_irq, NULL, NULL); > irq_set_probe(irq); > - irqd_set_single_target(irq_desc_get_irq_data(irq_to_desc(irq))); > + irqd_set_single_target(irqd); > break; > > case LPI_RANGE: > @@ -1310,6 +1311,8 @@ static int gic_irq_domain_map(struct irq_domain > *d, unsigned int irq, > return -EPERM; > } > > + /* Prevents SW retriggers which mess up the ACK/EOI ordering */ > + irqd_set_handle_enforce_irqctx(irqd); > return 0; > } > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index e2b4cae88bce..a91ce1e73bd2 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -983,6 +983,7 @@ static int gic_irq_domain_map(struct irq_domain > *d, unsigned int irq, > irq_hw_number_t hw) > { > struct gic_chip_data *gic = d->host_data; > + struct irq_data *irqd = irq_desc_get_irq_data(irq_to_desc(irq)); > > if (hw < 32) { > irq_set_percpu_devid(irq); > @@ -992,8 +993,11 @@ static int gic_irq_domain_map(struct irq_domain > *d, unsigned int irq, > irq_domain_set_info(d, irq, hw, &gic->chip, d->host_data, > handle_fasteoi_irq, NULL, NULL); > irq_set_probe(irq); > - irqd_set_single_target(irq_desc_get_irq_data(irq_to_desc(irq))); > + irqd_set_single_target(irqd); > } > + > + /* Prevents SW retriggers which mess up the ACK/EOI ordering */ > + irqd_set_handle_enforce_irqctx(irqd); > return 0; > } I'm OK with this in principle, but this requires additional changes in the rest of the GIC universe. The ITS driver needs to provide its own retrigger function for LPIs (queuing an INT command), and any of the SPI generating widgets that can be stacked on top of a GIC (GICv3-MBI, GICv2m, and all the other Annapurna/Marvell/NVDIA wonders need to gain directly or indirectly a call to irq_chip_retrigger_hierarchy(). We can probably avoid changing the MSI widgets by teaching the MSI code about the HW retrigger, but a number of other non-MSI drivers will need some help... I'll have a look tomorrow. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel