Re: [PATCH 08/17] KVM: pfncache: Return -EAGAIN for a lookup which hits an invalid memslot

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: ABBA deadlock in kvm_xen_set_evtchn() against memslot updates
--

commit d08948c3f01d34b213b2379e1b128830ccb5f086
Author: David Woodhouse <dwmw@amazon.co.uk>

KVM: pfncache: Return -EAGAIN for a lookup which hits an invalid memslot

This commit modifies the pfncache lookup to return -EAGAIN when a memslot
is marked KVM_MEMSLOT_INVALID. It also updates kvm_xen_set_evtchn() to
indefinitely retry the refresh on -EAGAIN instead of failing.

> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index b6643b889320d..0b49eb67d06c0 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -2026,7 +2026,17 @@ static int kvm_xen_set_evtchn(struct kvm_xen_evtchn *xe, struct kvm *kvm)
>  		idx = srcu_read_lock(&kvm->srcu);
>  		rc = kvm_gpc_refresh(gpc, PAGE_SIZE);
>  		srcu_read_unlock(&kvm->srcu, idx);
> -	} while(!rc);
> +
> +		/*
> +		 * A refresh which raced with a concurrent memslot update
> +		 * (-EAGAIN: the slot exists but is mid-DELETE/MOVE) will
> +		 * succeed once the update completes or reverts; giving up
> +		 * instead would drop the event. Only a genuinely unbacked
> +		 * gfn (-EFAULT etc.) is fatal.
> +		 */
> +		if (rc == -EAGAIN)
> +			cond_resched();
> +	} while (!rc || rc == -EAGAIN);

[Severity: High]
Does this create an ABBA deadlock against memslot updates when called from
the vcpu_run() path?

A guest VM issuing an EVTCHNOP_send hypercall operates inside vcpu_run(),
which holds the outer kvm->srcu read lock. If this races with a VMM memslot
update (e.g., KVM_SET_USER_MEMORY_REGION), kvm_xen_set_evtchn() will encounter
-EAGAIN and loop here waiting for the update to complete.

However, cond_resched() does not drop the outer kvm->srcu lock. The thread
performing the memslot update is blocked in synchronize_srcu(&kvm->srcu)
waiting for all existing readers (including this vCPU thread) to drop their
locks.

This results in an unbreakable deadlock where the vCPU thread waits for the
memslot update, while the update waits for the vCPU thread to drop kvm->srcu.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260920211920.928306-1-dwmw2@infradead.org?part=8