From: Yuho Choi <oss.patchbox@gmail.com>
To: Eric Farman <farman@linux.ibm.com>,
Matthew Rosato <mjrosato@linux.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
Alex Williamson <alex@shazbot.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
Vineeth Vijayan <vneethv@linux.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, Yuho Choi <oss.patchbox@gmail.com>
Subject: [PATCH v1] vfio/ccw: Flush notoper_work before returning from reset
Date: Tue, 22 Sep 2026 12:49:28 -0400 [thread overview]
Message-ID: <20260922164928.477669-1-oss.patchbox@gmail.com> (raw)
vfio_ccw_dma_unmap() is the DMA invalidation callback, which must unpin
the pages covering the range before it returns. It calls
vfio_ccw_mdev_reset(), which raises a CLOSE event.
On the normal path fsm_close() calls cp_free() itself, so the pages are
unpinned synchronously. But if the subchannel cannot be disabled or
quiesced, fsm_close() falls through to a NOT_OPER event, and fsm_notoper()
only queues notoper_work, which is where cp_free() then runs. Nothing
waits for that work, so the callback returns with the pages still pinned.
Because notoper_work runs asynchronously, vfio_dma_do_unmap() can exhaust
its 10 retries before cp_free() completes, hitting BUG_ON(++retries > 10)
and taking the host down. A further CLOSE cannot help either, as both
CLOSE and OPEN are fsm_nop in the NOT_OPER state.
Flush notoper_work after the CLOSE event, as vfio_ccw_mdev_close_device()
already does for the same reason. The flush returns immediately when the
work was never queued, so the normal path is unaffected.
Fixes: ce4b4657ff18 ("vfio: Replace the DMA unmapping notifier with a callback")
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
---
Found by code review. Cross-compiled for s390 with gcc 14.3.0, W=1 clean,
but not tested on s390 hardware and I have no reproducer.
VFIO_DEVICE_RESET also reaches vfio_ccw_mdev_reset() and benefits from
this flush, ensuring channel program memory is cleanly released before
the reset ioctl returns.
On locking: the flush is not called with io_mutex held. cp_iova_pinned()
takes and drops it before vfio_ccw_mdev_reset() runs, vfio_ccw_fsm_event()
takes no lock, and the VFIO_DEVICE_RESET path holds nothing. This matches
vfio_ccw_mdev_close_device(), which already flushes the same work.
drivers/s390/cio/vfio_ccw_ops.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 5ce91285c7d5..8e0a2edbd34a 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -25,6 +25,14 @@ static int vfio_ccw_mdev_reset(struct vfio_ccw_private *private)
* and re-opening the mdev, return an error.
*/
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_CLOSE);
+
+ /*
+ * A failed CLOSE leaves the FSM Not Operational and defers cp_free()
+ * to notoper_work. Wait for it, so the channel program pages are
+ * unpinned before this returns.
+ */
+ flush_work(&private->notoper_work);
+
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_OPEN);
if (private->state == VFIO_CCW_STATE_NOT_OPER)
return -EINVAL;
base-commit: f0100363d8c374bd8e9ea7c9ba02744f0b802ca4
--
2.43.0
next reply other threads:[~2026-09-22 16:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 16:49 Yuho Choi [this message]
2026-09-22 17:01 ` [PATCH v1] vfio/ccw: Flush notoper_work before returning from reset 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=20260922164928.477669-1-oss.patchbox@gmail.com \
--to=oss.patchbox@gmail.com \
--cc=alex@shazbot.org \
--cc=farman@linux.ibm.com \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=vneethv@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.