All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Jose Fernandez (Anthropic)" <jose.fernandez@linux.dev>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>, Tom Murphy <murphyt7@tcd.ie>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Mohammed Almaroof <moh@anthropic.com>,
	Ben Cressey <ben@cressey.dev>
Subject: Re: [PATCH 6.18.y] iommu/vt-d: Gather the unmapped range before freeing its page tables
Date: Thu, 13 Aug 2026 10:34:15 -0300	[thread overview]
Message-ID: <20260813133415.GK662699@ziepe.ca> (raw)
In-Reply-To: <20260813-b4-vtd-unmap-gather-v1-1-4c52f4a7a1ac@linux.dev>

On Thu, Aug 13, 2026 at 12:05:26AM +0000, Jose Fernandez (Anthropic) wrote:
> Under a userspace driver that maps and unmaps DMA buffers through VFIO
> type1 continuously, this shows up as wrong data in device reads and
> writes. An occasional DMAR fault on a mapped IOVA is the only thing in
> the logs. With an Intel DSA engine assigned through vfio-pci, remapping
> a 16 MiB buffer at a fixed IOVA and reading it through the device
> returned data from the wrong pages in 280 of 400 iterations. With a
> fresh IOVA per iteration it never did.
> 
> Add the range to the gather first and splice the freed tables into
> gather->freelist afterwards, so that they are only freed by a sync that
> also invalidates their range.
> 
> Mainline removed this code in v6.19 with commit d373449d8e97
> ("iommu/vt-d: Use the generic iommu page table") and is not affected.

Yeah, I noticed this bug category in iommupt at some point, I didn't
realize there was long existing errors in the drivers.

I don't know what the process is to put a unique patch into stable
(backporting the upstream iommupt based fix is not reasonable), but
this looks correct to me, it follows the pattern iommupt is using and
I have now extensively tested.

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

  reply	other threads:[~2026-08-13 13:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  0:05 [PATCH 6.18.y] iommu/vt-d: Gather the unmapped range before freeing its page tables Jose Fernandez (Anthropic)
2026-08-13 13:34 ` Jason Gunthorpe [this message]
2026-08-15  2:33 ` Sasha Levin

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=20260813133415.GK662699@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=baolu.lu@linux.intel.com \
    --cc=ben@cressey.dev \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=jose.fernandez@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=moh@anthropic.com \
    --cc=murphyt7@tcd.ie \
    --cc=robin.murphy@arm.com \
    --cc=stable@vger.kernel.org \
    --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.