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 D510AC433F5 for ; Fri, 29 Apr 2022 23:34:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346141AbiD2XhU (ORCPT ); Fri, 29 Apr 2022 19:37:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245492AbiD2XhT (ORCPT ); Fri, 29 Apr 2022 19:37:19 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1808D444F for ; Fri, 29 Apr 2022 16:33:56 -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 ams.source.kernel.org (Postfix) with ESMTPS id 67544B837ED for ; Fri, 29 Apr 2022 23:33:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B8ECC385A4; Fri, 29 Apr 2022 23:33:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651275234; bh=kuzfadshogv8txXF2JbgijRcZ15/H/uwFDbXFLPP0BY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eRIr/i/j3QYU4aaZFcoqBA69Zw07VDXk905gX6pX6Eqq/D4z0GuZ6P655jQxXvDfP SpK7xjmmQe6OiPGVHrb8+kGOnFtFZVrASz7Z/Gly8ztCZS+zyPHHO0qwthaaa5dQH9 qfNYJKkshQm0v3nXcpR+AtktxtcLbuX0dMZEyaEOmZdCq3veOq46lLCdG0kgcZ+x+l JumQdoNQqEz/H7Uora60z8p5dGNODotkCb81rMC5zb9AijDmnq3ztE6Wm5OU9/Qur4 HsoarAqjsR2Tnd41D+dygHoJ6qs4g0JB92Ddh1R661y7T6glD0nGuD4WmDS/N9Tn8B lmW1FSfQW1HXw== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nka7T-0083oN-HP; Sat, 30 Apr 2022 00:33:51 +0100 Date: Sat, 30 Apr 2022 00:33:51 +0100 Message-ID: <87h76b8nxc.wl-maz@kernel.org> From: Marc Zyngier To: Bjorn Helgaas Cc: Conor.Dooley@microchip.com, lorenzo.pieralisi@arm.com, Daire.McNamara@microchip.com, bhelgaas@google.com, Cyril.Jean@microchip.com, david.abdurachmanov@gmail.com, linux-pci@vger.kernel.org, robh@kernel.org Subject: Re: [RESEND PATCH v1 1/1] PCI: microchip: Fix potential race in interrupt handling In-Reply-To: <20220429215733.GA97739@bhelgaas> References: <79102463-adc1-9555-70ba-bdde58a77401@microchip.com> <20220429215733.GA97739@bhelgaas> 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/27.1 (x86_64-pc-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: helgaas@kernel.org, Conor.Dooley@microchip.com, lorenzo.pieralisi@arm.com, Daire.McNamara@microchip.com, bhelgaas@google.com, Cyril.Jean@microchip.com, david.abdurachmanov@gmail.com, linux-pci@vger.kernel.org, robh@kernel.org 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-pci@vger.kernel.org On Fri, 29 Apr 2022 22:57:33 +0100, Bjorn Helgaas wrote: > > [+to Marc] > > On Fri, Apr 29, 2022 at 09:42:52AM +0000, Conor.Dooley@microchip.com wrote: > > On 28/04/2022 10:29, Lorenzo Pieralisi wrote: > > > On Tue, Apr 05, 2022 at 12:17:51PM +0100, daire.mcnamara@microchip.com wrote: > > >> From: Daire McNamara > > >> > > >> Clear MSI bit in ISTATUS register after reading it before > > >> handling individual MSI bits > > > > > > That explains nothing. If you are fixing a bug please describe > > > the issue and how the patch is fixing it. > > > > Someone in the pantheon of IT gods has it out for Daire, so I am > > sending this on his behalf, but is the following revised commit > > message better? > > > > Clear the MSI bit in ISTATUS register after reading it, but before > > reading and handling individual MSI bits from the IMSI register. > > This avoids a potential race where new MSI bits may be set on the > > IMSI register after it was read and be missed when the MSI bit in > > the ISTATUS register is cleared. > > "ISTATUS" doesn't appear in the code as a register name. Neither does > "IMSI". Please use names that match the code. > > Honestly, I don't understand enough about IRQs to determine whether > this is a correct fix. Hopefully Marc will chime in. All I really > know how to do is compare all the drivers and see which ones don't fit > the typical patterns. This seems sensible. In general, edge interrupts need an early Ack *before* the handler can be run. If it happens after, you're pretty much guaranteed to lose edges that would be generated between the handler and the late Ack. This can be implemented in HW in a variety of ways (read a register, write a register, or even both). > > And speaking of that, I looked at all the users of > irq_set_chained_handler_and_data() in drivers/pci. All the handlers > except mc_handle_intx() and mc_handle_msi() call chained_irq_enter() > and chained_irq_exit(). > > Are mc_handle_intx() and mc_handle_msi() just really special, or is > this a mistake? That's just a bug. On the right HW, this would just result in lost interrupts. M. -- Without deviation from the norm, progress is not possible.