All of lore.kernel.org
 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 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.