All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
	iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>
Cc: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>,
	Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>,
	Joerg Roedel <joerg.roedel@amd.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	patches@lists.linux.dev, Samiullah Khawaja <skhawaja@google.com>,
	stable@vger.kernel.org,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH rc 1/2] iommu: Do not call drivers for empty gathers
Date: Tue, 31 Mar 2026 18:12:18 +0100	[thread overview]
Message-ID: <8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com> (raw)
In-Reply-To: <1-v1-13a02eb0e031+a5-iommu_gather_jgg@nvidia.com>

Hi Jason,

On 02/03/2026 22:22, Jason Gunthorpe wrote:
> An empty gather is coded with start=U64_MAX, end=0 and several drivers go
> on to convert that to a size with:
> 
>   end - start + 1
> 
> Which gives 2 for an empty gather. This then causes Weird Stuff to
> happen (for example an UBSAN splat in VT-d) that is hopefully harmless,
> but maybe not.
> 
> Prevent drivers from being called right in iommu_iotlb_sync().
> 
> Auditing shows that AMD, Intel, Mediatek and RSIC-V drivers all do things
> on these empty gathers.
> 
> Further, there are several callers that can trigger empty gathers,
> especially in unusual conditions. For example iommu_map_nosync() will call
> a 0 size unmap on some error paths. Also in VFIO, iommupt and other
> places.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> Closes: https://lore.kernel.org/r/11145826.aFP6jjVeTY@jkrzyszt-mobl2.ger.corp.intel.com
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
>   include/linux/iommu.h | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 54b8b48c762e88..555597b54083cd 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -980,7 +980,8 @@ static inline void iommu_flush_iotlb_all(struct iommu_domain *domain)
>   static inline void iommu_iotlb_sync(struct iommu_domain *domain,
>   				  struct iommu_iotlb_gather *iotlb_gather)
>   {
> -	if (domain->ops->iotlb_sync)
> +	if (domain->ops->iotlb_sync &&
> +	    likely(iotlb_gather->start < iotlb_gather->end))
>   		domain->ops->iotlb_sync(domain, iotlb_gather);
>   
>   	iommu_iotlb_gather_init(iotlb_gather);


I noticed that a couple of our Tegra boards are no longer booting -next 
and bisect pointed to this commit. Reverting this does fix it.

This is impacting our Tegra186 (using nvidia,tegra186-smmu compatible 
string) and Tegra194 (using nvidia,tegra194-smmu compatible string) 
boards. There is no specific crash I see, but the boards just appear to 
hang on boot. If you have any thoughts or things to try let me know.

Thanks!
Jon

-- 
nvpublic


  parent reply	other threads:[~2026-03-31 17:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-02 22:22 [PATCH rc 0/2] Fix two bugs in iommu gather processing Jason Gunthorpe
2026-03-02 22:22 ` [PATCH rc 1/2] iommu: Do not call drivers for empty gathers Jason Gunthorpe
2026-03-03  9:08   ` Vasant Hegde
2026-03-03 12:53   ` Robin Murphy
2026-03-03 13:04     ` Jason Gunthorpe
2026-03-03 15:56       ` Robin Murphy
2026-03-19 10:02         ` Janusz Krzysztofik
2026-03-03 18:30   ` Samiullah Khawaja
2026-03-04  7:19   ` Baolu Lu
2026-03-31 17:12   ` Jon Hunter [this message]
2026-03-31 19:58     ` Jason Gunthorpe
2026-03-02 22:22 ` [PATCH rc 2/2] iommupt: Fix short gather if the unmap goes into a large mapping Jason Gunthorpe
2026-03-03  9:08   ` Vasant Hegde
2026-03-03 18:30   ` Samiullah Khawaja
2026-03-04  7:20   ` Baolu Lu

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=8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=iommu@lists.linux.dev \
    --cc=janusz.krzysztofik@linux.intel.com \
    --cc=jgg@nvidia.com \
    --cc=joerg.roedel@amd.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=patches@lists.linux.dev \
    --cc=robin.murphy@arm.com \
    --cc=skhawaja@google.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.