All paths leading to handle_essa() already hold the kvm->srcu.
Remove unneeded srcu locking from handle_essa().
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
---
arch/s390/kvm/priv.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
index 1a49b89706f8..758cefb5bac7 100644
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -1297,12 +1297,8 @@ static int handle_essa(struct kvm_vcpu *vcpu)
/* Retry the ESSA instruction */
kvm_s390_retry_instr(vcpu);
} else {
- int srcu_idx;
-
mmap_read_lock(vcpu->kvm->mm);
- srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
i = __do_essa(vcpu, orc);
- srcu_read_unlock(&vcpu->kvm->srcu, srcu_idx);
mmap_read_unlock(vcpu->kvm->mm);
if (i < 0)
return i;
--
2.49.0On Wed, 2025-05-14 at 18:38 +0200, Claudio Imbrenda wrote:
> All paths leading to handle_essa() already hold the kvm->srcu.
> Remove unneeded srcu locking from handle_essa().
>
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Why are you removing it tho?
It should be very low cost and it makes the code more robust,
since handle_essa itself ensures that it has the lock.
It is also easier to understand which synchronization the function does.
You could of course add a comment stating that the kvm srcu read side needs
to be held. I think this would be good to have if you really don't want the
srcu_read_lock here.
But then you might also want that documented up the call chain.
> ---
> arch/s390/kvm/priv.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
> index 1a49b89706f8..758cefb5bac7 100644
> --- a/arch/s390/kvm/priv.c
> +++ b/arch/s390/kvm/priv.c
> @@ -1297,12 +1297,8 @@ static int handle_essa(struct kvm_vcpu *vcpu)
> /* Retry the ESSA instruction */
> kvm_s390_retry_instr(vcpu);
> } else {
> - int srcu_idx;
> -
> mmap_read_lock(vcpu->kvm->mm);
> - srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
> i = __do_essa(vcpu, orc);
> - srcu_read_unlock(&vcpu->kvm->srcu, srcu_idx);
> mmap_read_unlock(vcpu->kvm->mm);
> if (i < 0)
> return i;
--
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
On Mon, 2025-05-19 at 16:42 +0200, Nina Schoetterl-Glausch wrote:
> On Wed, 2025-05-14 at 18:38 +0200, Claudio Imbrenda wrote:
> > All paths leading to handle_essa() already hold the kvm->srcu.
> > Remove unneeded srcu locking from handle_essa().
> >
> > Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
>
> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
>
> Why are you removing it tho?
> It should be very low cost and it makes the code more robust,
> since handle_essa itself ensures that it has the lock.
> It is also easier to understand which synchronization the function does.
> You could of course add a comment stating that the kvm srcu read side needs
> to be held. I think this would be good to have if you really don't want the
> srcu_read_lock here.
> But then you might also want that documented up the call chain.
Actually, can we use __must_hold or have some assert?
>
> > ---
> > arch/s390/kvm/priv.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
> > index 1a49b89706f8..758cefb5bac7 100644
> > --- a/arch/s390/kvm/priv.c
> > +++ b/arch/s390/kvm/priv.c
> > @@ -1297,12 +1297,8 @@ static int handle_essa(struct kvm_vcpu *vcpu)
> > /* Retry the ESSA instruction */
> > kvm_s390_retry_instr(vcpu);
> > } else {
> > - int srcu_idx;
> > -
> > mmap_read_lock(vcpu->kvm->mm);
> > - srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
> > i = __do_essa(vcpu, orc);
> > - srcu_read_unlock(&vcpu->kvm->srcu, srcu_idx);
> > mmap_read_unlock(vcpu->kvm->mm);
> > if (i < 0)
> > return i;
--
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
Am 20.05.25 um 16:34 schrieb Nina Schoetterl-Glausch: > On Mon, 2025-05-19 at 16:42 +0200, Nina Schoetterl-Glausch wrote: >> On Wed, 2025-05-14 at 18:38 +0200, Claudio Imbrenda wrote: >>> All paths leading to handle_essa() already hold the kvm->srcu. >>> Remove unneeded srcu locking from handle_essa(). >>> >>> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> >> >> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> >> >> Why are you removing it tho? >> It should be very low cost and it makes the code more robust, >> since handle_essa itself ensures that it has the lock. >> It is also easier to understand which synchronization the function does. >> You could of course add a comment stating that the kvm srcu read side needs >> to be held. I think this would be good to have if you really don't want the >> srcu_read_lock here. >> But then you might also want that documented up the call chain. > > Actually, can we use __must_hold or have some assert? Yes, that might be the best way.
Am 14.05.25 um 18:38 schrieb Claudio Imbrenda:
> All paths leading to handle_essa() already hold the kvm->srcu.
You could add
since commit 800c1065c320 ("KVM: s390: Lock kvm->srcu at the appropriate places").
> Remove unneeded srcu locking from handle_essa().
>
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> ---
> arch/s390/kvm/priv.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
> index 1a49b89706f8..758cefb5bac7 100644
> --- a/arch/s390/kvm/priv.c
> +++ b/arch/s390/kvm/priv.c
> @@ -1297,12 +1297,8 @@ static int handle_essa(struct kvm_vcpu *vcpu)
> /* Retry the ESSA instruction */
> kvm_s390_retry_instr(vcpu);
> } else {
> - int srcu_idx;
> -
> mmap_read_lock(vcpu->kvm->mm);
> - srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
> i = __do_essa(vcpu, orc);
> - srcu_read_unlock(&vcpu->kvm->srcu, srcu_idx);
> mmap_read_unlock(vcpu->kvm->mm);
> if (i < 0)
> return i;
© 2016 - 2026 Red Hat, Inc.