From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C9B622083; Sat, 11 Jul 2026 22:25:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783808718; cv=none; b=fbpjP3HNawMA8xXxN+wckJdHxUBndicPZj0LAIwwPdxWdiBLCKBDerfUXo21a+zkmAPSFO+Ex8GaeqeS9LsQNm8pyqLeKmt0cowblluo8uqCfUdWoXui+p6H/sC6UAl3J1T3l0wP9vARLkOY/jqKV4gFRdCNAQ/Fha/twOSIoEM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783808718; c=relaxed/simple; bh=1DKLGXqbvwNsveEROP3E0ZnDDoJNGA74F7AD/1CH8cg=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=fEhPyu5VM613JfNjTD0CC9RT25nTDuEYIqBRZQBpcKHmyKs5/BVbpYQGzggPjCjl201GLPmcp78kDHikLRqcLtV/GIMiWit2YH+fRuWg2oGEm4Npp1LMF6ZSaFPZ/HD4zNtUep6VLTa8b3stNAVNugXOMVklKBRjh5bIF1xKb8w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AzR1w56U; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AzR1w56U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A98D1F000E9; Sat, 11 Jul 2026 22:25:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783808717; bh=MroNGxfh3roGHcEzCx5geFAiRpldVnVdU+HOskzSHq4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=AzR1w56UB9twHSbzooZLUaXLteCniD0ciVhOr5yU5XUtpRPuhRzfxLgg589S4TsI9 8IXHUDBym10/imbCTvAEXGyiuUYcszxkDtmAJMM/f+2Xl8MD1TCIOzJ162XIRYDTeS d5U0iP5nHxmSWsoxRE3Cj7OL55XMMARC8evfPZKCwyVTLNlmi3MhjzFwTOLnggpypE Ev74SoRM7UisUDOCX5I+OceyaS3Ejmv2iDGrf+4q0584Rze8EsFhqqibCjEyjFOKLb OTAqGbBIp8xuKHlhYDo3sP6GV1aU5eeB4gYUyevCuyIxgT9r5bgC65TDsVQ16516jl D+XXoybHkpddg== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wig8J-000000044d6-0XSM; Sat, 11 Jul 2026 22:25:15 +0000 Date: Sat, 11 Jul 2026 23:27:04 +0100 Message-ID: <87jyr15fif.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: "D Scott Phillips" , "Oliver Upton" , kvmarm@lists.linux.dev Subject: Re: [PATCH] arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29 In-Reply-To: <20260710223718.2C85B1F000E9@smtp.kernel.org> References: <20260710222128.416581-1-scott@os.amperecomputing.com> <20260710223718.2C85B1F000E9@smtp.kernel.org> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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: sashiko-reviews@lists.linux.dev, scott@os.amperecomputing.com, oupton@kernel.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 10 Jul 2026 23:37:17 +0100, sashiko-bot@kernel.org wrote: [...] > [Severity: High] > This isn't a bug introduced by this patch, but does dropping irq->irq_lock > between computing the LR snapshot and folding it create a race condition that > loses concurrent virtual interrupts? > > vgic_v3_deactivate() takes the lock, computes the snapshot, and then the > scoped_guard ends: > > scoped_guard(raw_spinlock, &irq->irq_lock) { > ... > lr = vgic_v3_compute_lr(vcpu, irq) & ~ICH_LR_ACTIVE_BIT; > } > > If a concurrent device injects an interrupt here via vgic_inject_irq() and > sets irq->pending_latch = true, won't the subsequent call to > vgic_v3_fold_lr(vcpu, lr) re-acquire the lock and evaluate the stale snapshot? > > vgic_v3_fold_lr() would see !(val & ICH_LR_STATE) is true and execute: > > if (irq->config == VGIC_CONFIG_LEVEL && !(val & ICH_LR_STATE)) > irq->pending_latch = false; > > Could this wipe out the newly arrived interrupt and cause guest devices to > stall? Having thought about it (yes, this is what the NSJ is for), my conclusion is that this report is utter bollocks. The clearing of the latch obviously only applies to level interrupts, which can only be set by SW. The convention is that the Ack of a level interrupt consumes the latched signal (SW can't distinguish it from a device interrupt anyway). A *device* interrupt sets irq->line_level, and can only be dropped by the device itself, not by anything happening in the LR. My conclusion is that Sashiko doesn't understand the GIC interrupt life cycle, and is deeply confused by it. I'm shocked. M. -- Jazz isn't dead. It just smells funny.