[PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb

[Yosry Ahmed]

On Wed, Jun 10, 2026 at 3:57 AM Marc Zyngier <maz at kernel.org> wrote:
>
> On Tue, 09 Jun 2026 18:57:26 +0100,
> Yosry Ahmed <yosry at kernel.org> wrote:
> >
> > > > If yes, I think the code looks confusing, at least to a layman like
> > > > myself. It initially seems like the lock protects against concurrent
> > > > initializations, but then the NULL check is not done again under the
> > > > lock. The goal of the lock is not clear without the original report.
> > > >
> > > > Mayeb it's clearer to explicitly use barriers if the goal is preventing
> > > > reordering?
> > >
> > > This would require both the initialisation of vncr_tlb to use a store
> > > release, *and* all the other call sites to use a load acquire.
> > >
> > > I really don't think it is worth the churn, nor the (very small)
> > > burden on the readers.
> >
> > That's fair. I was mainly just pointing out my initial confusion and
> > that others may share it. Avoiding the churn on the readers' side is
> > understandable. Maybe a comment here would help explain why the lock
> > needs to be held?
>
> I have added this:
>
>         /*
>          * Taking the lock on assignment ensures that the TLB is
>          * seen as initialised when following the pointer (release
>          * semantics of the unlock), and avoids having acquires on
>          * each user which already take the lock.
>          */

Looks good, thank you!