From: "Christoph Schlameuss" <schlameuss@linux.ibm.com>
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>,
<linux-kernel@vger.kernel.org>
Cc: <kvm@vger.kernel.org>, <linux-s390@vger.kernel.org>,
<borntraeger@de.ibm.com>, <frankja@linux.ibm.com>,
<david@kernel.org>, <seiden@linux.ibm.com>, <nrb@linux.ibm.com>,
<schlameuss@linux.ibm.com>, <gra@linux.ibm.com>
Subject: Re: [PATCH v2 6/9] KVM: s390: Fix IRQ injection with SIGP Stop and Store Status
Date: Wed, 12 Aug 2026 14:59:36 +0200 [thread overview]
Message-ID: <DKMZFBBD13PQ.1588PLS4LJS74@linux.ibm.com> (raw)
In-Reply-To: <20260812104436.109741-7-imbrenda@linux.ibm.com>
On Wed Aug 12, 2026 at 12:44 PM CEST, Claudio Imbrenda wrote:
> When __inject_sigp_stop() is called for a Stop and Store Status
> operation, if the vCPU is running, the interrupt is marked as pending
> and the status is stored by the thread performing the KVM_RUN IOCTL.
>
> If the vCPU is already stopped, the status is stored immediately.
>
> Storing the status means writing into userspace, which might fault, and
> __inject_sigp_stop() is called from do_inject_vcpu() which in turn is
> always called holding a spinlock, which is obviously an issue.
>
> Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and
> adding a bool flag to indicate whether a store status is needed. The
> callers of do_inject_vcpu() are modified to pass the pointer to the
> bool flag; whenever a Store Status operation is needed, the callers can
> now perform it outside the spinlock.
>
> Opportunistically refactor kvm_s390_set_irq_state() to use
> scoped_guard() and __free().
>
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> ---
> arch/s390/kvm/interrupt.c | 70 +++++++++++++++++++++------------------
> 1 file changed, 38 insertions(+), 32 deletions(-)
>
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 8e4b88bce31f..6940f4d354e5 100644
[...]
> @@ -3188,31 +3192,33 @@ int kvm_s390_set_irq_state(struct kvm_vcpu *vcpu, void __user *irqstate, int len
> if (!buf)
> return -ENOMEM;
>
> - if (copy_from_user((void *) buf, irqstate, len)) {
> - r = -EFAULT;
> - goto out_free;
> - }
> + if (copy_from_user((void *)buf, irqstate, len))
> + return -EFAULT;
>
> - /*
> - * Don't allow setting the interrupt state
> - * when there are already interrupts pending
> - */
> - spin_lock(&li->lock);
> - if (li->pending_irqs) {
> - r = -EBUSY;
> - goto out_unlock;
> - }
> + scoped_guard(spinlock, &li->lock) {
> + /*
> + * Don't allow setting the interrupt state
> + * when there are already interrupts pending
> + */
> + if (li->pending_irqs)
> + return -EBUSY;
>
> - for (n = 0; n < len / sizeof(*buf); n++) {
> - r = do_inject_vcpu(vcpu, &buf[n]);
> - if (r)
> - break;
> + for (n = 0; n < len / sizeof(*buf); n++) {
> + tmp = false;
> + r = do_inject_vcpu(vcpu, &buf[n], &tmp);
> + if (r == -EWOULDBLOCK && tmp) {
> + storestatus = true;
> + r = 0;
> + }
> + if (r)
> + break;
> + }
> }
>
> -out_unlock:
> - spin_unlock(&li->lock);
> -out_free:
> - vfree(buf);
> + if (storestatus) {
> + n = kvm_s390_store_status_unloaded(vcpu, KVM_S390_STORE_STATUS_NOADDR);
I assume we do not care about loosing n = -EFAULT when we are already on the
error path here with r != 0. But are there cases in which we would not want to
call kvm_s390_store_status_unloaded() at all here when one of the later
do_inject_vcpu() calls failed with a specific error?
> + return r ? r : n;
> + }
>
> return r;
> }
next prev parent reply other threads:[~2026-08-12 12:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 10:44 [PATCH v2 0/9] KVM: s390: And then... even more fixes again Claudio Imbrenda
2026-08-12 10:44 ` [PATCH v2 1/9] KVM: s390: Properly handle NULL pointer in dat_cond_set_storage_key() Claudio Imbrenda
2026-08-12 10:55 ` sashiko-bot
2026-08-12 10:44 ` [PATCH v2 2/9] KVM: s390: Use srcu in kvm_arch_vcpu_unlocked_ioctl() Claudio Imbrenda
2026-08-12 10:58 ` sashiko-bot
2026-08-12 11:02 ` Christoph Schlameuss
2026-08-12 10:44 ` [PATCH v2 3/9] KVM: s390: Fix get_all_floating_irqs() Claudio Imbrenda
2026-08-12 10:55 ` Christian Borntraeger
2026-08-12 10:55 ` sashiko-bot
2026-08-12 14:06 ` Christoph Schlameuss
2026-08-12 10:44 ` [PATCH v2 4/9] KVM: s390: Fix dirty marking in adapter_indicators_set*() Claudio Imbrenda
2026-08-12 11:00 ` sashiko-bot
2026-08-12 11:03 ` Christian Borntraeger
2026-08-12 11:37 ` Claudio Imbrenda
2026-08-12 10:44 ` [PATCH v2 5/9] KVM: s390: Fix pgste_get_trylock_multiple() Claudio Imbrenda
2026-08-12 10:50 ` sashiko-bot
2026-08-12 11:11 ` Christoph Schlameuss
2026-08-12 10:44 ` [PATCH v2 6/9] KVM: s390: Fix IRQ injection with SIGP Stop and Store Status Claudio Imbrenda
2026-08-12 10:53 ` sashiko-bot
2026-08-12 12:59 ` Christoph Schlameuss [this message]
2026-08-12 13:11 ` Claudio Imbrenda
2026-08-12 13:23 ` Christoph Schlameuss
2026-08-12 10:44 ` [PATCH v2 7/9] KVM: s390: Fix kvm_s390_clear_pv_state() Claudio Imbrenda
2026-08-12 10:53 ` sashiko-bot
2026-08-12 13:02 ` Christoph Schlameuss
2026-08-12 10:44 ` [PATCH v2 8/9] KVM: s390: Fix potential tiny kernel stack leak Claudio Imbrenda
2026-08-12 10:53 ` sashiko-bot
2026-08-12 13:14 ` Christoph Schlameuss
2026-08-12 10:44 ` [PATCH v2 9/9] KVM: s390: Fix _gaccess_shadow_fault() Claudio Imbrenda
2026-08-12 11:47 ` 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=DKMZFBBD13PQ.1588PLS4LJS74@linux.ibm.com \
--to=schlameuss@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=gra@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=seiden@linux.ibm.com \
/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.