From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v4 03/13] KVM: s390: Fix race in __do_essa()
Date: Tue, 28 Jul 2026 17:21:25 +0000 [thread overview]
Message-ID: <20260728172126.3F1F91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728170708.294400-4-imbrenda@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Meaningful code, documentation, and commit message mismatch regarding which lock is used.
--
--- Patch [3]: [PATCH v4 03/13] KVM: s390: Fix race in __do_essa() ---
commit 44561620d155e5433777595f8bc3b2d06087934d
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
KVM: s390: Fix race in __do_essa()
This patch fixes a potential race condition between __do_essa() and the
migration and CMMA state handling functions. It transitions the affected paths
to use the architecture-specific slots lock via scope-based guards.
> KVM: s390: Fix race in __do_essa()
>
> An unlikely race between __do_essa() and kvm_s390_vm_start_migration(),
> kvm_s390_vm_stop_migration(), or dat_get_cmma() was possible.
>
> Fix by locking kvm->slots_lock. Since this is not a hot path, the
> overhead of an additional mutex is negligible.
[Severity: Medium]
This isn't a bug, but the commit message states the fix uses kvm->slots_lock,
while the code changes actually use kvm->slots_arch_lock. Should the commit
message be updated to reflect the use of the architecture-specific lock?
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 89de085f39670..1952f592a80a1 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1298,7 +1298,9 @@ static int kvm_s390_vm_set_migration(struct kvm *kvm,
> {
> int res = -ENXIO;
>
> - mutex_lock(&kvm->slots_lock);
> + guard(srcu)(&kvm->srcu);
> + guard(mutex)(&kvm->slots_arch_lock);
[Severity: Medium]
This isn't a bug, but the function documentation for kvm_s390_vm_start_migration()
and kvm_s390_vm_stop_migration() (which are called from here) still states they
must be called with kvm->slots_lock held:
arch/s390/kvm/kvm-s390.c:kvm_s390_vm_start_migration():
/*
* Must be called with kvm->srcu held to avoid races on memslots, and with
* kvm->slots_lock to avoid races with ourselves, kvm_s390_vm_stop_migration(),
* and kvm_s390_get_cmma_bits().
*/
static int kvm_s390_vm_start_migration(struct kvm *kvm)
Since these paths now use kvm->slots_arch_lock instead, would it be helpful
to update those comments to match the new locking behavior?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260728170708.294400-1-imbrenda@linux.ibm.com?part=3
next prev parent reply other threads:[~2026-07-28 17:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 17:06 [PATCH v4 00/13] KVM: s390: Misc fixes Claudio Imbrenda
2026-07-28 17:06 ` [PATCH v4 01/13] KVM: s390: Fix unlikely NULL gmap dereference Claudio Imbrenda
2026-07-28 17:27 ` sashiko-bot
2026-07-28 17:06 ` [PATCH v4 02/13] KVM: s390: Fix leaking of PGM_ADDRESSING to userspace Claudio Imbrenda
2026-07-28 17:16 ` sashiko-bot
2026-07-28 17:06 ` [PATCH v4 03/13] KVM: s390: Fix race in __do_essa() Claudio Imbrenda
2026-07-28 17:21 ` sashiko-bot [this message]
2026-07-28 17:06 ` [PATCH v4 04/13] KVM: s390: cmma: Fix dirty tracking when removing memslot Claudio Imbrenda
2026-07-28 17:22 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 05/13] KVM: s390: ucontrol: Add missing locking around gmap_remove_child() Claudio Imbrenda
2026-07-28 17:20 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 06/13] KVM: s390: Fix overclearing ESCA in case of error Claudio Imbrenda
2026-07-28 17:27 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 07/13] KVM: s390: Return -EINTR if a signal was pending while faulting-in Claudio Imbrenda
2026-07-28 17:32 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 08/13] KVM: s390: Free the mmu cache when kvm_arch_vcpu_create() fails Claudio Imbrenda
2026-07-28 17:27 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 09/13] KVM: s390: Fix ordering when adding to SCA Claudio Imbrenda
2026-07-28 17:15 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 10/13] KVM: s390: Fix cleanup in kvm_s390_pv_create_cpu() Claudio Imbrenda
2026-07-28 17:14 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 11/13] KVM: s390: Fix kvm_arch_commit_memory_region() when low on memory Claudio Imbrenda
2026-07-28 17:25 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 12/13] KVM: s390: Fix kvm_s390_vcpu_unsetup_cmma() Claudio Imbrenda
2026-07-28 17:24 ` sashiko-bot
2026-07-28 17:07 ` [PATCH v4 13/13] KVM: s390: Fix sca_clear_ext_call() for UCONTROL Claudio Imbrenda
2026-07-28 17:39 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260728172126.3F1F91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.