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 04936C433EF for ; Wed, 9 Mar 2022 10:46:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231411AbiCIKq4 (ORCPT ); Wed, 9 Mar 2022 05:46:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbiCIKqz (ORCPT ); Wed, 9 Mar 2022 05:46:55 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1489870306 for ; Wed, 9 Mar 2022 02:45:52 -0800 (PST) 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 7632861692 for ; Wed, 9 Mar 2022 10:45:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4E47C340E8; Wed, 9 Mar 2022 10:45:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646822751; bh=qTVyIhfbBVTO5sKZ2n6PGQiUip6qu5eGE2Y3guMVcII=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EAApjbuAFe8KeV4VCfdEDk+B5bTfBVGWsSTqOFHo9tu7C8JcRPelxyfeoLNCfquQx yImyroOjCSf1hj9HCpVPllVQdn60Cyfa6oXBdwVXUJNeImAW/1DbpogLq9buhXO+vp KGecnSBXP+IMigokp1YgfUj6fMOI/d3GKGmvzRhsxOZj+QNHxPs0LOVi611qczxJbQ JiZOhM8Mn/9S5Po76sSXkJWm5k/U+1D70QFvJ7Xc0DmY+jeft4y8QKpyXQLibFLoZx nHmhIY1ugEOT3D0JteiN6eg6x7kAwdsY54p+2Lt9rdclA9X8tC+L6h6ixc+TdwNGpG xaMAaQtbNE4nw== 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 1nRtpF-00DIII-E9; Wed, 09 Mar 2022 10:45:49 +0000 Date: Wed, 09 Mar 2022 10:45:49 +0000 Message-ID: <87wnh3z9nm.wl-maz@kernel.org> From: Marc Zyngier To: Jason Wang , Will Deacon Cc: mst@redhat.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, f.hetzelt@tu-berlin.de, david.kaplan@amd.com, konrad.wilk@oracle.com, Boqun Feng , Thomas Gleixner , Peter Zijlstra , "Paul E . McKenney" , keirf@google.com Subject: Re: [PATCH V3 05/10] virtio-pci: harden INTX interrupts In-Reply-To: <20211019070152.8236-6-jasowang@redhat.com> References: <20211019070152.8236-1-jasowang@redhat.com> <20211019070152.8236-6-jasowang@redhat.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/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: jasowang@redhat.com, will@kernel.org, mst@redhat.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, f.hetzelt@tu-berlin.de, david.kaplan@amd.com, konrad.wilk@oracle.com, boqun.feng@gmail.com, tglx@linutronix.de, peterz@infradead.org, paulmck@kernel.org, keirf@google.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 [Adding Will to check on my understanding of the interactions between spinlocks and WRITE_ONCE()] On Tue, 19 Oct 2021 08:01:47 +0100, Jason Wang wrote: > > This patch tries to make sure the virtio interrupt handler for INTX > won't be called after a reset and before virtio_device_ready(). We > can't use IRQF_NO_AUTOEN since we're using shared interrupt > (IRQF_SHARED). So this patch tracks the INTX enabling status in a new > intx_soft_enabled variable and toggle it during in > vp_disable/enable_vectors(). The INTX interrupt handler will check > intx_soft_enabled before processing the actual interrupt. > > Cc: Boqun Feng > Cc: Thomas Gleixner > Cc: Peter Zijlstra > Cc: Paul E. McKenney > Signed-off-by: Jason Wang > --- > drivers/virtio/virtio_pci_common.c | 23 +++++++++++++++++++++-- > drivers/virtio/virtio_pci_common.h | 1 + > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c > index 8d8f83aca721..1bce254a462a 100644 > --- a/drivers/virtio/virtio_pci_common.c > +++ b/drivers/virtio/virtio_pci_common.c > @@ -30,8 +30,16 @@ void vp_disable_cbs(struct virtio_device *vdev) > struct virtio_pci_device *vp_dev = to_vp_device(vdev); > int i; > > - if (vp_dev->intx_enabled) > + if (vp_dev->intx_enabled) { > + /* > + * The below synchronize() guarantees that any > + * interrupt for this line arriving after > + * synchronize_irq() has completed is guaranteed to see > + * intx_soft_enabled == false. > + */ > + WRITE_ONCE(vp_dev->intx_soft_enabled, false); > synchronize_irq(vp_dev->pci_dev->irq); > + } > > for (i = 0; i < vp_dev->msix_vectors; ++i) > disable_irq(pci_irq_vector(vp_dev->pci_dev, i)); > @@ -43,8 +51,16 @@ void vp_enable_cbs(struct virtio_device *vdev) > struct virtio_pci_device *vp_dev = to_vp_device(vdev); > int i; > > - if (vp_dev->intx_enabled) > + if (vp_dev->intx_enabled) { > + disable_irq(vp_dev->pci_dev->irq); > + /* > + * The above disable_irq() provides TSO ordering and > + * as such promotes the below store to store-release. > + */ > + WRITE_ONCE(vp_dev->intx_soft_enabled, true); What do you mean by TSO here? AFAICT, the CPU is allowed hoist this write up into the lock used by disable_irq(), as the unlock only has release semantics. Is that what you are relying on? I don't see how this upgrades WRITE_ONCE() to have release semantics. > + enable_irq(vp_dev->pci_dev->irq); Same thing does here: my understanding is that the write can be pushed down into the lock, which has acquire semantics only. Thanks, M. -- Without deviation from the norm, progress is not possible.