All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: Robin Murphy <robin.murphy@arm.com>, Jason Gunthorpe <jgg@nvidia.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	Will Deacon	 <will@kernel.org>,
	Alejandro Jimenez <alejandro.j.jimenez@oracle.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: Thu, 19 Mar 2026 11:02:18 +0100	[thread overview]
Message-ID: <60a007aeebab10377b66951d958e711ae89e573a.camel@linux.intel.com> (raw)
In-Reply-To: <ed985e72-dbfe-4d60-b5f1-581ba58e3c18@arm.com>

Hi,

On Tue, 2026-03-03 at 15:56 +0000, Robin Murphy wrote:
> On 2026-03-03 1:04 pm, Jason Gunthorpe wrote:
> > 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..
> 
> I reckon an early "if (!size) return 0;" in iommu_unmap() would suffice 
> to cover the internal error cleanup paths and most careless external 
> users. However if we don't trust iommu_unmap_fast() users to always do 
> the right thing either then we want this check in iommu_iotlb_sync() 
> anyway, at which point the iommu_unmap() check would really only serve 
> to skip a bit more unnecessary work on error cleanup paths, and do we 
> really care about optimising errors? Hence I'm satisfied that this patch 
> does in fact seem to be the best option.

Is this patch going to be applied soon to one of your branches? I'm 
waiting for that to happen because I want to cherry-pick it and propose as 
a temporary fix to be applied to our core-for-CI sub-branch of drm-tip 
until the original lands in mainline.

Thanks,
Janusz

> 
> > > > -	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?
> 
> No, that's fine, I just wanted to confirm the intent - this isn't a 
> place where we should need to be concerned about micro-optimising to 
> maybe save a load and an extra ALU op or two, just that I don't think 
> it's worth doing any more than strictly necessary for our own 
> robustness. Thus there's no need to change the check in 
> iommu_iotlb_gather_is_disjoint() either, as that now just serves to skip 
> the redundant reinitialisation of an already-empty gather, which is 
> justifiably a different thing from the actual validity-of-sync condition 
> anyway.
> 
> Cheers,
> Robin.

  reply	other threads:[~2026-03-19 10:02 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 [this message]
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=60a007aeebab10377b66951d958e711ae89e573a.camel@linux.intel.com \
    --to=janusz.krzysztofik@linux.intel.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.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.