From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CEFF825948F for ; Mon, 30 Dec 2024 14:28:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735568895; cv=none; b=lQGJ+SDC1j8S+tkqEhIqu5/GT6qfrgR9jSTIzdvwmaJoLXDFh3K6PrQpo5+JjzOchzvJEj3aghUhjXXS86QOYYjmV2+IjUuMXDZjbFLZBmHrLdFav/Y71ST3kdq2s8JStkZtP6IU6BndB4wlemoicKRvHjE+IYSoIZlLDnZXHuQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735568895; c=relaxed/simple; bh=bJfVi+BMiEEb7eekd/qq5JTHVPBWFbUY4Q+gpgU7aFM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=CtgM6dCNkuiZB8AIgTFpwhXZD2B/HghxDRyR8h1dUN0hV3NTxNlRNkvtYtKesMxsY3RbBqcj31wHKCDL8LfOtICNgp6ruG5nu09jLa7Bmej+7z8WWHD1A3PsuVywsOn6PTk5ginfA+LcKxc4UY96iubeUhMycwBaNeYLxeukU78= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Viy8qfRI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Viy8qfRI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54663C4CED0; Mon, 30 Dec 2024 14:28:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735568895; bh=bJfVi+BMiEEb7eekd/qq5JTHVPBWFbUY4Q+gpgU7aFM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Viy8qfRIvvPF1VKPbk3riNaxxvw5IwfUr6hIYBEvlO+l4XrVXjnl2k9TNOogBS/NG fF5sAnudFONxlQNbMDsumyyMSjuz5cQWGS/zDdJudELVz46kdAGBa+cJBChkO5Wzpn 6gpbquUqOwDRk32Gjy+LI2ByJyrAyYmX45ZZxptItLVidevwiLIevy84p/6P5VFk70 nyJ35PLAZugtVoKDeh0l3Hfxj9xYyFZq3CO+W9S7asnuwvAlhZFqvJZPp6oomUOX+Q A5dq8v1JWCbyAyMqcGYBf/bXGPCjCnQ2526n9GNiacgzOSuEr49w2UPQ9mvo1D/Ytr y/zAbtUXxi7yQ== 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 1tSGkf-007pr0-0X; Mon, 30 Dec 2024 14:28:13 +0000 Date: Mon, 30 Dec 2024 14:28:12 +0000 Message-ID: <86h66lp7nn.wl-maz@kernel.org> From: Marc Zyngier To: Tomas Krcka Cc: linux-arm-kernel@lists.infradead.org, nh-open-source@amazon.com, Tomas Krcka , Thomas Gleixner , Hagar Hemdan , linux-kernel@vger.kernel.org Subject: Re: [PATCH] irqchip/gic-v3-its: fix raw_local_irq_restore() called with IRQs enabled In-Reply-To: <20241230134903.84613-1-krckatom@amazon.de> References: <20241230134903.84613-1-krckatom@amazon.de> 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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org 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: tomas.krcka@gmail.com, linux-arm-kernel@lists.infradead.org, nh-open-source@amazon.com, krckatom@amazon.de, tglx@linutronix.de, hagarhem@amazon.com, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hi Tomas, On Mon, 30 Dec 2024 13:49:03 +0000, Tomas Krcka wrote: > > The following call-chain leads to misuse of spinlock_irq > when spinlock_irqsave was hold. > > irq_set_vcpu_affinity > -> irq_get_desc_lock (spinlock_irqsave) > -> its_irq_set_vcpu_affinity > -> guard(raw_spin_lock_irq) <--- this enables interrupts > -> irq_put_desc_unlock // <--- WARN IRQs enabled Urgh. Nice catch. It really should have been either raw_spin_lock or the _irqsave variant, but not the _irq variant which should really never be used outside of the core code. I guess this was never really tested when rewritten at commit time... > Fix the issue by using guard(raw_spinlock), since the function is > already called with irqsave and raw_spin_lock was used before the commit > b97e8a2f7130 ("irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()") > introducing the guard as well. > > This was discovered through the lock debugging, and the corresponding > log is as follows: > > raw_local_irq_restore() called with IRQs enabled > WARNING: CPU: 38 PID: 444 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x2c/0x38 > Call trace: > warn_bogus_irq_restore+0x2c/0x38 > _raw_spin_unlock_irqrestore+0x68/0x88 > __irq_put_desc_unlock+0x1c/0x48 > irq_set_vcpu_affinity+0x74/0xc0 > its_map_vlpi+0x44/0x88 > kvm_vgic_v4_set_forwarding+0x148/0x230 > kvm_arch_irq_bypass_add_producer+0x20/0x28 > __connect+0x98/0xb8 > irq_bypass_register_consumer+0x150/0x178 > kvm_irqfd+0x6dc/0x744 > kvm_vm_ioctl+0xe44/0x16b0 > > Fixes: b97e8a2f7130 ("irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()") > Signed-off-by: Tomas Krcka Two problems here: - there is no "From Tomas Krcka " at the beginning of the patch, which is needed since you are posting from a gmail.com address - there is no SoB using your gmail.com address, which is needed since this patch appears to be from your Amazon doppelganger. So either you post this patch from your amazon.de email, or you add the two missing pieces of information that are required. > --- > drivers/irqchip/irq-gic-v3-its.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 92244cfa0464..8c3ec5734f1e 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -2045,7 +2045,7 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) > if (!is_v4(its_dev->its)) > return -EINVAL; > > - guard(raw_spinlock_irq)(&its_dev->event_map.vlpi_lock); > + guard(raw_spinlock)(&its_dev->event_map.vlpi_lock); This otherwise looks good to me. Please repost this with the above issues fixed, and the following tags: Reviewed-by: Marc Zyngier Cc: stable@vger.kernel.org Thanks, M. -- Without deviation from the norm, progress is not possible.