Re: [PATCH v1 03/11] KVM: arm64: Use guard()/scoped_guard() in arm64 KVM EL1 code

[Fuad Tabba]

On Thu, 18 Jun 2026 at 10:41, Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> On Thu, 18 Jun 2026 10:24:55 +0100,
> Fuad Tabba <tabba@xxxxxxxxxx> wrote:
> >
> > On Thu, 18 Jun 2026 at 10:23, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> > >
> > > On Fri, 12 Jun 2026 07:59:17 +0100,
> > > tabba@xxxxxxxxxx wrote:
> > > >
> > > > Convert the manual mutex_lock()/spin_lock() pairs in
> > > > arch/arm64/kvm/{pkvm,arm,mmu,reset,psci}.c to guard(mutex),
> > > > guard(spinlock) and scoped_guard(), dropping unlock-only goto labels in
> > > > favour of direct returns. Centralised cleanup gotos that still serve
> > > > other resources are preserved.
> > > >
> > > > reset.c uses scoped_guard() rather than guard() so the lock covers only
> > > > the small read/update window inside kvm_reset_vcpu(), leaving the rest
> > > > of the function outside the critical section.
> > >
> > > To be brutally honest, I don't think this sort of widespread changes
> > > bring us anything. This is just churn.
> > >
> > > Sure, if you are reworking a particular bit of code that is goto-heavy
> > > for the purpose of error handling, this has the potential to cleanup
> > > the code *while you are changing it*.
> > >
> > > But doing it for the sake of doing it? I think we have bigger fish to
> > > fry right now.
> >
> > I understand what you mean. Would you like me to drop all of the guard
> > patches, or only those that go beyond the code changed in this series?
>
> The latter. I'm fine with conversion that happens while the code is
> being reworked.

Sure, I'll do that on the respin.

Cheers,
/fuad

>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.