All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	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
Subject: Re: [PATCH rc 1/2] iommu: Do not call drivers for empty gathers
Date: Tue, 3 Mar 2026 09:04:20 -0400	[thread overview]
Message-ID: <20260303130420.GB972761@nvidia.com> (raw)
In-Reply-To: <13e28ac2-a4d6-466a-aef2-7b3d7d9167bd@arm.com>

On Tue, Mar 03, 2026 at 12:53:28PM +0000, Robin Murphy wrote:

> > 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.
> 
> My instinct is still to tidy up the 0-length unmap case(s), but I guess
> iommu_iotlb_sync() is itself also a public API where being more robust
> against erroneous usage is no bad thing. 

I also wanted to do that but found enough problematic cases I lost
confidence I could reliably catch them all..

> > -	if (domain->ops->iotlb_sync)
> > +	if (domain->ops->iotlb_sync &&
> > +	    likely(iotlb_gather->start < iotlb_gather->end))
> 
> Elsewhere we just use "gather->end != 0" as the "non-empty" condition; how
> concerned are we about defending against more-intentionally malformed
> gathers here?

I choose this deliberately to protect the driver, a malformed gather
that is 0 sized, or negative sized looks like it will have Weird
Things happen in drivers.

We could further classify the < and WARN_ON the malformed cases, but I
don't want to pass negative sized gathers into drivers. We'd probably
also have to de-inline the function if more is added. Do you have a
preference?

Jason

  reply	other threads:[~2026-03-03 13:04 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 [this message]
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
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=20260303130420.GB972761@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=iommu@lists.linux.dev \
    --cc=janusz.krzysztofik@linux.intel.com \
    --cc=joerg.roedel@amd.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --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.