Re: [PATCH v2 5/8] KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping

[Marc Zyngier <maz@kernel.org>]

On Thu, 06 Aug 2026 10:25:39 +0100,
sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Acquiring `mmu_lock` with preemption disabled causes a sleep-in-atomic bug on PREEMPT_RT kernels.
> --
> 
> --- Patch [5]: [PATCH v2 5/8] KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping ---
> commit 7a7c469ac4158e77c3548a526ab62a924ed75161
> Author: Marc Zyngier <maz@kernel.org>
> 
> KVM: arm64: Handle VNCR TLB invalidation race with vcpu_put() VNCR unmapping
> 
> This patch addresses a race condition between VNCR TLB invalidation and VNCR
> unmapping during vcpu_put(). It introduces an atomic exchange for resetting
> the cpu tracking field and a common function for unmapping, ensuring these
> operations happen atomically. This closes the TOCTOU race and prevents
> concurrent mapping faults.
> 
> Link: https://lore.kernel.org/r/20260801130237.0FD8F1F00ACA@smtp.kernel.org
> 
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index 67cc5b6d80705..05f0e7e89e982 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> 
> [ ... ]
> 
> > @@ -1584,8 +1607,6 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
> 
> [Severity: High]
> This is a pre-existing issue, but does acquiring mmu_lock inside a
> preemption-disabled region here cause a sleep-in-atomic bug on RT kernels?
> 
> Looking at kvm_map_l1_vncr() from the context, it starts with:
> 
> static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
> {
>         struct vncr_tlb *vt = vcpu->arch.vncr_tlb;
>         pgprot_t prot;
> 
>         guard(preempt)();
>         guard(read_lock)(&vcpu->kvm->mmu_lock);
> 
> Since read_lock() is implemented as an RT-mutex on PREEMPT_RT and can block,
> could this sequence trigger a scheduling-while-atomic panic if the lock is
> contended?

I think we need to understand what that means for the state of the
fixmap if we get preempted at this point.

I think it is OK as long as the read_lock itself disables preemption
but this is sketchy. In any case, RT+NV is not something I wish to
think about right now.

	M.

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