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

[Marc Zyngier]

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.
	 */

Thanks,

	M.

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