All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yuho Choi" <oss.patchbox@gmail.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>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH v2] vfio/ccw: Flush notoper_work before returning from reset
Date: Fri, 06 Nov 2026 19:21:47 +0000	[thread overview]
Message-ID: <sashiko-outbox-202148@kernel.org> (raw)
In-Reply-To: <20261106191029.469837-2-oss.patchbox@gmail.com>

> 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.  Since commit
> 0c11f61a876e ("s390/vfio_ccw: Move cp cleanup out of not operational"),
> fsm_notoper() only queues notoper_work, which is where cp_free() then
> runs.  That commit flushes the work in vfio_ccw_mdev_close_device() and
> vfio_ccw_mdev_release_dev(), but nothing waits for it on the reset
> path, 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.  The flush returns immediately when the work was never
> queued, so the normal path is unaffected.
> 
> Fixes: 0c11f61a876e ("s390/vfio_ccw: Move cp cleanup out of not operational")
> Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106191029.469837-2-oss.patchbox@gmail.com?part=1


  reply	other threads:[~2026-11-06 19:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 19:10 [PATCH v2] vfio/ccw: Flush notoper_work before returning from reset Yuho Choi
2026-11-06 19:21 ` sashiko-bot [this message]
2026-11-09 12:38 ` Christian Borntraeger
2026-11-09 14:49   ` Jason Gunthorpe
2026-11-09 19:40     ` Christian Borntraeger
2026-11-09 18:15   ` Yuho Choi

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=sashiko-outbox-202148@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=oss.patchbox@gmail.com \
    --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.