Re: [PATCH v1 5/8] KVM: s390: Fix race in __do_essa()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Acquiring `kvm->slots_lock` inside an SRCU read-side critical section causes an ABBA deadlock.
--

commit e40855b84f2ee647bcced37d340b4d6805640050
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>

KVM: s390: Fix race in __do_essa()

This commit addresses a race condition between __do_essa() and VM migration
or dat_get_cmma() by acquiring kvm->slots_lock before calling __do_essa().

> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
> --- a/arch/s390/kvm/priv.c
> +++ b/arch/s390/kvm/priv.c
> @@ -1260,8 +1260,9 @@ static int handle_essa(struct kvm_vcpu *vcpu)
>  		/* Retry the ESSA instruction */
>  		kvm_s390_retry_instr(vcpu);
>  	} else {
> -		scoped_guard(read_lock, &vcpu->kvm->mmu_lock)
> -			i = __do_essa(vcpu, orc);
> +		scoped_guard(mutex, &vcpu->kvm->slots_lock)
> +			scoped_guard(read_lock, &vcpu->kvm->mmu_lock)
> +				i = __do_essa(vcpu, orc);

[Severity: High]
Does acquiring kvm->slots_lock here introduce an ABBA deadlock?

Looking at handle_essa(), it executes within an SRCU read-side critical
section, as verified by the lockdep assertion at the start of the function:

static int handle_essa(struct kvm_vcpu *vcpu)
{
	lockdep_assert_held(&vcpu->kvm->srcu);
	...

If a concurrent memslot update acquires kvm->slots_lock and then calls
synchronize_srcu(&kvm->srcu), it will wait on the SRCU lock held by this
thread, while this thread blocks waiting for kvm->slots_lock.

>  		if (i < 0)
>  			return i;
>  		/* Account for the possible extra cbrl entry */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702152406.204782-1-imbrenda@linux.ibm.com?part=5