All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leonro@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <iommu@lists.linux.dev>, "Joerg Roedel (AMD)" <joro@8bytes.org>,
	"Robin Murphy" <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Luis Chamberlain <mcgrof@kernel.org>, Mark Lord <mlord@pobox.com>,
	<patches@lists.linux.dev>, <stable@vger.kernel.org>
Subject: Re: [PATCH rc] iommu/dma: Do not try to iommu_map a 0 length region in swiotlb
Date: Tue, 9 Jun 2026 17:52:19 +0300	[thread overview]
Message-ID: <20260609145219.GC327369@unreal> (raw)
In-Reply-To: <0-v1-8536728bc89f+469-swiotlb_warn_jgg@nvidia.com>

On Mon, Jun 08, 2026 at 03:10:04PM -0300, Jason Gunthorpe wrote:
> iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three
> parts, the head, middle and trailer. If the middle is empty because there
> are no aligned pages it will call down to iommu_map() with a 0 size
> which the iommupt implementation will fail as illegal.
> 
> It then tries to do an error unwind and starts from the wrong spot
> corrupting the mapping so the eventual destruction triggers a WARN_ON.
> 
> Check for 0 length and avoid mapping and use offset not 0 as the starting
> point to unlink.
> 
> This is frequently triggered by using some kinds of thunderbolt NVMe
> drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to
> pass in oddly aligned buffers for the passthrough commands from smartctl
> that hit this condition.
> 
> Cc: stable@vger.kernel.org
> Fixes: 433a76207dcf ("dma-mapping: Implement link/unlink ranges API")
> Reported-by: Mark Lord <mlord@pobox.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
>  drivers/iommu/dma-iommu.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> This was discovered because iommupt errors on mapping length=0 instead of
> making it a NOP, so it is an became an issue since commit d6c65b0fd621
> ("iommupt: Avoid rewalking during map") making it a regression this merge
> window.
> 

Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>

  parent reply	other threads:[~2026-06-09 14:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260608181015eucas1p241dfd8c16072125dc760072a080d4cd2@eucas1p2.samsung.com>
2026-06-08 18:10 ` [PATCH rc] iommu/dma: Do not try to iommu_map a 0 length region in swiotlb Jason Gunthorpe
2026-06-09  8:36   ` Christoph Hellwig
2026-06-09 14:52   ` Leon Romanovsky [this message]
2026-06-09 17:03   ` Samiullah Khawaja
2026-06-09 20:26   ` Marek Szyprowski

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=20260609145219.GC327369@unreal \
    --to=leonro@nvidia.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mcgrof@kernel.org \
    --cc=mlord@pobox.com \
    --cc=patches@lists.linux.dev \
    --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.