public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Oliver Upton <oupton@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	"KERNEL VIRTUAL MACHINE FOR ARM64 KVM/arm64"
	<linux-arm-kernel@lists.infradead.org>,
	"KERNEL VIRTUAL MACHINE FOR ARM64 KVM/arm64"
	<kvmarm@lists.linux.dev>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/10] KVM: arm64: Adopt scoped resource management (guard) for EL1 and EL2
Date: Tue, 17 Mar 2026 08:20:34 +0000	[thread overview]
Message-ID: <86v7eu6f59.wl-maz@kernel.org> (raw)
In-Reply-To: <20260316-tabba-el2_guard-v1-0-456875a2c6db@google.com>

On Mon, 16 Mar 2026 17:35:21 +0000,
Fuad Tabba <tabba@google.com> 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.

  parent reply	other threads:[~2026-03-17  8:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16 17:35 [PATCH 00/10] KVM: arm64: Adopt scoped resource management (guard) for EL1 and EL2 Fuad Tabba
2026-03-16 17:35 ` [PATCH 01/10] KVM: arm64: Add scoped resource management (guard) for hyp_spinlock Fuad Tabba
2026-03-16 17:35 ` [PATCH 02/10] KVM: arm64: Use guard(hyp_spinlock) in page_alloc.c Fuad Tabba
2026-03-16 17:35 ` [PATCH 03/10] KVM: arm64: Use guard(hyp_spinlock) in ffa.c Fuad Tabba
2026-03-17 17:40   ` Jonathan Cameron
2026-03-17 18:01     ` Fuad Tabba
2026-03-16 17:35 ` [PATCH 04/10] KVM: arm64: Use guard(hyp_spinlock) in mm.c Fuad Tabba
2026-03-17 17:44   ` Jonathan Cameron
2026-03-16 17:35 ` [PATCH 05/10] KVM: arm64: Use guard(hyp_spinlock) in pkvm.c Fuad Tabba
2026-03-17 17:47   ` Jonathan Cameron
2026-03-16 17:35 ` [PATCH 06/10] KVM: arm64: Use guard(mutex) in mmu.c Fuad Tabba
2026-03-17 17:50   ` Jonathan Cameron
2026-03-16 17:35 ` [PATCH 07/10] KVM: arm64: Use scoped resource management in arm.c Fuad Tabba
2026-03-17 17:53   ` Jonathan Cameron
2026-03-16 17:35 ` [PATCH 08/10] KVM: arm64: Use guard(spinlock) in psci.c Fuad Tabba
2026-03-17 17:54   ` Jonathan Cameron
2026-03-16 17:35 ` [PATCH 09/10] KVM: arm64: Use guard(spinlock) in reset.c Fuad Tabba
2026-03-16 17:35 ` [PATCH 10/10] KVM: arm64: Use guard(mutex) in pkvm.c Fuad Tabba
2026-03-16 17:39 ` [PATCH 00/10] KVM: arm64: Adopt scoped resource management (guard) for EL1 and EL2 Fuad Tabba
2026-03-17  8:20 ` Marc Zyngier [this message]
2026-03-17  9:06   ` Fuad Tabba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86v7eu6f59.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oupton@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox