All of lore.kernel.org
 help / color / mirror / Atom feed
From: YeeLi <seven.yi.lee@gmail.com>
To: joro@8bytes.org, will@kernel.org
Cc: robin.murphy@arm.com, jgg@ziepe.ca, iommu@lists.linux.dev
Subject: [PATCH 1/2] iommupt: fix full IOTLB flush from a zero length unmap
Date: Thu,  5 Nov 2026 20:12:26 +0800	[thread overview]
Message-ID: <20261105121227.622631-2-seven.yi.lee@gmail.com> (raw)
In-Reply-To: <20261105121227.622631-1-seven.yi.lee@gmail.com>

From: yeeli <seven.yi.lee@gmail.com>

unmap_range() hands gather_range_pending() the number of bytes it
actually unmapped, not the requested length. That count is 0 whenever
the range holds no mappings, so an unmap that removes nothing reaches
the gather code with len == 0.

The gather helpers assume a real range: both
iommu_iotlb_gather_add_range() and iommu_iotlb_gather_is_disjoint()
compute end = iova + len - 1. For len == 0 this wraps to iova - 1.

The problem can be reproduced by attaching an empty paging domain to an
Intel VT-d device and unmapping IOVA 0:

	domain = iommu_paging_domain_alloc(dev);
	iommu_attach_device(domain, dev);
	iommu_unmap(domain, 0, PAGE_SIZE);	/* nothing is mapped */

The unmap returns 0, but the gather becomes [0, ULONG_MAX] and the
iotlb_sync() that follows asks the driver to invalidate everything.
Captured with the cache_tag_flush_range and qi_submit tracepoints
enabled:

  cache_tag_flush_range: dmar0 dmar0[0] type iotlb did 12 [0x0-0xffffffffffffffff] addr 0x0 mask 0x34
  qi_submit: p_iotlb_inv dmar0: 0xc0026 0x0 0x0 0x0

With a non-zero IOVA the wrapped end widens whatever range has already
been gathered instead.

Skip the gather bookkeeping when nothing was unmapped. An untouched
gather keeps start == ULONG_MAX and end == 0, which iommu_iotlb_sync()
already ignores.

Fixes: 7c53f4238aa8 ("iommupt: Add unmap_pages op")
Signed-off-by: yeeli <seven.yi.lee@gmail.com>
---
 drivers/iommu/generic_pt/iommu_pt.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/generic_pt/iommu_pt.h b/drivers/iommu/generic_pt/iommu_pt.h
index 837d835e4fad..566cae4bc217 100644
--- a/drivers/iommu/generic_pt/iommu_pt.h
+++ b/drivers/iommu/generic_pt/iommu_pt.h
@@ -83,8 +83,13 @@ static void gather_range_pending(struct iommupt_pending_gather *pending,
 	 * For NO_GAPS the user gets to pick if flushing all or doing micro
 	 * flushes is better for their work load by choosing DMA vs DMA-FQ
 	 * operation. Drivers should also see shadow_on_flush.
+	 *
+	 * A zero length unmap (len == 0) means nothing was unmapped and must
+	 * not create a gather range: iova + len - 1 wraps around, and at IOVA 0
+	 * the resulting degenerate range [0, ULONG_MAX] would turn into a full
+	 * IOTLB flush.
 	 */
-	if (!iommu_iotlb_gather_queued(iotlb_gather)) {
+	if (len && !iommu_iotlb_gather_queued(iotlb_gather)) {
 		if (pt_feature(common, PT_FEAT_FLUSH_RANGE_NO_GAPS) &&
 		    iommu_iotlb_gather_is_disjoint(iotlb_gather, iova, len)) {
 			iommu_iotlb_sync(&iommu_table->domain, iotlb_gather);
-- 
2.34.1


  reply	other threads:[~2026-11-05 12:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 12:12 [PATCH 0/2] iommupt: fix zero-length unmap causing a full IOTLB flush YeeLi
2026-11-05 12:12 ` YeeLi [this message]
2026-11-09  6:59   ` [PATCH 1/2] iommupt: fix full IOTLB flush from a zero length unmap Baolu Lu
2026-11-05 12:12 ` [PATCH 2/2] iommupt: add a KUnit test for unmapping an empty range YeeLi

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=20261105121227.622631-2-seven.yi.lee@gmail.com \
    --to=seven.yi.lee@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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.