Linux virtualization list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Anlai Lu" <agicy@qq.com>
Cc: "Eugenio Perez" <eperezma@redhat.com>,
	virtualization@lists.linux.dev,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v2 4/6] iommu/virtio: stop queueing and draining once the device is removed
Date: Sun, 04 Oct 2026 13:11:51 +0000	[thread overview]
Message-ID: <20261004131151.D405D1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <tencent_5FCFC7891F9B565EBA65B56B951EDC219B08@qq.com>

> viommu_remove() resets the device and deletes the virtqueues while
> userspace may still hold domains that it maps or attaches, and nothing
> stopped a request from being queued - or a drain from walking the queue -
> on a virtqueue that was being torn down.
> 
> Set ->removed under request_lock before the teardown - the lock a
> queueing path holds while it checks liveness and adds the request, and
> the one the drain holds for its whole run - check it in the queueing
> helper, and let the drain return early when it is set.
> 
> A drain that returns early leaves the requests still on the queue
> behind, and the device cannot complete them either.  Detach them
> from the request virtqueue - which unmaps their DMA mappings - and
> free them after the device is reset, when it can no longer be using
> them, and before the queues are deleted, so that the objects do not
> leak.
> 
> Fixes: edcd69ab9a32 ("iommu: Add virtio-iommu driver")
> Signed-off-by: Anlai Lu <agicy@qq.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_D757B544955DDC509B5DC7161F425620BA08@qq.com?part=4


  reply	other threads:[~2026-10-04 13:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-04 12:59 [PATCH v2 0/6] iommu/virtio: batch the mapping replay Anlai Lu
2026-10-04 13:01 ` [PATCH v2 1/6] iommu/virtio: publish the endpoint before replaying it Anlai Lu
2026-10-04 13:09   ` sashiko-bot
2026-10-04 13:01 ` [PATCH v2 2/6] iommu/virtio: queue an UNMAP for every removed mapping Anlai Lu
2026-10-04 13:15   ` sashiko-bot
2026-10-04 13:01 ` [PATCH v2 3/6] iommu/virtio: allocate the UNMAP request with the mapping Anlai Lu
2026-10-04 13:09   ` sashiko-bot
2026-10-04 13:01 ` [PATCH v2 4/6] iommu/virtio: stop queueing and draining once the device is removed Anlai Lu
2026-10-04 13:11   ` sashiko-bot [this message]
2026-10-04 13:01 ` [PATCH v2 5/6] iommu/virtio: read the endpoint count under the lock in the iotlb paths Anlai Lu
2026-10-04 13:08   ` sashiko-bot
2026-10-04 13:01 ` [PATCH v2 6/6] iommu/virtio: batch the mapping replay on domain attach Anlai Lu
2026-10-04 13:08   ` 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=20261004131151.D405D1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agicy@qq.com \
    --cc=eperezma@redhat.com \
    --cc=mst@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=virtualization@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox