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 027C639B4AF; Tue, 17 Mar 2026 08:20:37 +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=1773735638; cv=none; b=Co0nARFpAYBuH5+FSiidJ7H8eC6hVOZD+S9QnFsk+UAB0zxH805lQP+ik8Hv5Gy7tsndMTkNfggVMA51WXPKC7mU5uclGICw1Xq3ORMH2IZMQ2JaY+2HpchiLDg9AsV+tjTpMBfrc7c//1Fi1eTQXMGH/6DyOv43lPd2u+pf/bs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773735638; c=relaxed/simple; bh=VQNGXk1va0JojLCa5FTgduK6/uhqV70yDcBBQE/5J40=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cJRWw8IhzAZ5T5qYVNZmbH3S4ur47jgR/gD/lHcX/MCr1sD0YDVd9+XAmEmOYVIOTi/I5trtF/LWkidY0YgfSX9fhQFD5BuKjvJlWUWgG+tWmc04GjwyZQRQJpWzw7qPMvcXiBjTd18JF80iR1owiiFT6cPGB26qyCldJ+sjgdw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L2kTCLKJ; 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="L2kTCLKJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 852C1C2BC9E; Tue, 17 Mar 2026 08:20:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773735637; bh=VQNGXk1va0JojLCa5FTgduK6/uhqV70yDcBBQE/5J40=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=L2kTCLKJqOS5HvcFUgK480t6dsocDP43k7dp9YZ4h3bO+TaOUQ6TxqzWDPQSy9sAg cgc6Vxu2E2kx/JdVdZNzd7o8fJ5MU/DyPHfI7J8H188DI4B8Fi568eGIrIPWsEAcn1 ir9C2S5TKU6Bo8nUHWwEnSkI52KvNSLf/ws0gqR81LBB4+tIjiRKCIzNvpTrYf6N1w ZbCFYayAtr1aW5t6CQBLNeMTLQFNk14XqoLUelLRdytMfYZeWGCtB02ZalIGu/fnJe 43EW4CDNsVsoYFwUdcUs9TDhGBT1D9uT3l3O8v0tnLXHgH1GXXK0Ur2uLaCvacoo7k U4HFMjgCFGFxA== 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.98.2) (envelope-from ) id 1w2PfG-00000002jEv-3Wqu; Tue, 17 Mar 2026 08:20:34 +0000 Date: Tue, 17 Mar 2026 08:20:34 +0000 Message-ID: <86v7eu6f59.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , "KERNEL VIRTUAL MACHINE FOR ARM64 KVM/arm64" , "KERNEL VIRTUAL MACHINE FOR ARM64 KVM/arm64" , open list Subject: Re: [PATCH 00/10] KVM: arm64: Adopt scoped resource management (guard) for EL1 and EL2 In-Reply-To: <20260316-tabba-el2_guard-v1-0-456875a2c6db@google.com> References: <20260316-tabba-el2_guard-v1-0-456875a2c6db@google.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/30.1 (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: tabba@google.com, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, 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 On Mon, 16 Mar 2026 17:35:21 +0000, Fuad Tabba wrote: > > Hi everyone, > > I stumbled upon a lock leak while reviewing Sebastien's recent GIC Hardening > series [1] on an early error path. It reminded me that we've run into this exact > kind of bug pretty often while working on pKVM. Since we're going to be > hopefully upstream even more pKVM code soon, I'd like to try and fix this > pattern once and for all. I'm of the opposite opinion. I'd rather convert things as code gets modified, because this otherwise makes backporting patches a real pain (we have been through that exercise with the irq stack, and it wasn't an enjoyable experience). So while I'm not opposed to this in general, I'd rather see it as a prefix for new features, instead of a standalone series. [...] > There are definitely other parts of the KVM codebase that could benefit from > this (especially the vGIC), but I'm stopping here for now to see what everyone > thinks of the approach before touching anything else. The vgic is specially difficult to convert because of some of the constructs that take a lock in a function and release it in another, defeating the scope-based locking. I'll have a look at the series anyway. Thanks, M. -- Without deviation from the norm, progress is not possible.