From: Jason Gunthorpe <jgg@ziepe.ca>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Johan Hovold <johan@kernel.org>, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>, Sven Peter <sven@kernel.org>,
Janne Grunau <j@jannau.net>,
Rob Clark <robin.clark@oss.qualcomm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Yong Wu <yong.wu@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Chen-Yu Tsai <wens@csie.org>,
Thierry Reding <thierry.reding@gmail.com>,
Krishna Reddy <vdumpa@nvidia.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/14] iommu: fix device leaks
Date: Thu, 2 Oct 2025 10:01:17 -0300 [thread overview]
Message-ID: <20251002130116.GB3195829@ziepe.ca> (raw)
In-Reply-To: <2d94b52c-cffc-40af-930a-20f0130a23ea@arm.com>
On Thu, Oct 02, 2025 at 12:48:35PM +0100, Robin Murphy wrote:
> > However the SMMU drivers are doing this under the
> > iommu_probe_device_lock and not stashing the pointer into a drvdata
> > where there is no locking protecting it.
>
> Huh? Every .of_xlate call is under probe_device_lock just as much as
> .probe_device calls are; they *have* to be, since they too are in the
> position of working with dev->iommu before dev->iommu_group is set to
> guarantee its stability.
Yes, of_xlate is under the lock, but IIRC there are still cases where
probe gets deferred, the probe_device_lock is unlocked, and the
drvdata continues to exist.
> indeed the driver cannot be removed, because we hold a module reference
> around the call
That's not how module reference counts work. Drivers can be unbound
through sysfs at any time.
> > Anyhow, I drafted a nice fix for all of this. After all the rework it
> > is trivial for the core code to pass in the struct iommu_device * to
> > probe and then most of the drivers just drop this ugly code
> > completely.
> >
> > https://github.com/jgunthorpe/linux/commits/iommu-fwspec/
>
> Eww, that is neither nice nor a "fix". Once again it's just piling on a load
> of extra complexity to have multiple confusingly-overlapping-but-different
> ways of doing the same thing, one of which is still the exact same one
> you've decided to object to because you've failed to understand it (as
> demonstrated by the commit message below, the obvious bug in the hideous
> mess below that, and at a glance the other patches actively *breaking* at
> least one driver.)
It is hard to take you seriously with such vauge objections
Robin. Please try to be constructive. If you are specific I'll go fix
the things and maybe other people besides you can understand this
stuff.
I'm shocked you disagree with the core code helping the drivers find
their iommu_driver. This seems like very basic obvious good stuff. We
don't need all sorts of different open coded ugly ways for drivers to
do this. It removes 200 lines of junk for drivers :\
> > + iommu = fwspec_iommu->ops->probe_device(dev);
> > + if (IS_ERR(iommu))
> > + return PTR_ERR(iommu);
> > + if (WARN_ON(iommu != fwspec_iommu)) {
This is at least one typo.
Jason
next prev parent reply other threads:[~2025-10-02 13:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 12:27 Johan Hovold
2025-09-25 12:27 ` [PATCH 01/14] iommu/apple-dart: fix device leak on of_xlate() Johan Hovold
2025-09-25 12:27 ` [PATCH 02/14] iommu/qcom: " Johan Hovold
2025-09-25 12:27 ` [PATCH 03/14] iommu/exynos: " Johan Hovold
2025-09-25 12:27 ` [PATCH 04/14] iommu/ipmmu-vmsa: " Johan Hovold
2025-09-25 12:27 ` [PATCH 05/14] iommu/mediatek: " Johan Hovold
2025-09-25 12:27 ` [PATCH 06/14] iommu/mediatek: fix device leaks on probe() Johan Hovold
2025-09-25 12:27 ` [PATCH 07/14] iommu/mediatek: simplify dt parsing error handling Johan Hovold
2025-09-25 12:27 ` [PATCH 08/14] iommu/mediatek-v1: fix device leak on probe_device() Johan Hovold
2025-09-25 12:27 ` [PATCH 09/14] iommu/mediatek-v1: fix device leaks on probe() Johan Hovold
2025-09-25 12:27 ` [PATCH 10/14] iommu/mediatek-v1: add missing larb count sanity check Johan Hovold
2025-09-25 12:27 ` [PATCH 11/14] iommu/omap: fix device leaks on probe_device() Johan Hovold
2025-10-02 12:05 ` Robin Murphy
2025-10-02 14:45 ` Johan Hovold
2025-09-25 12:27 ` [PATCH 12/14] iommu/omap: simplify probe_device() error handling Johan Hovold
2025-09-25 12:27 ` [PATCH 13/14] iommu/sun50i: fix device leak on of_xlate() Johan Hovold
2025-09-25 12:27 ` [PATCH 14/14] iommu/tegra: fix device leak on probe_device() Johan Hovold
2025-09-30 18:21 ` [PATCH 00/14] iommu: fix device leaks Jason Gunthorpe
2025-09-30 19:35 ` Robin Murphy
2025-10-01 15:58 ` Jason Gunthorpe
2025-10-02 11:48 ` Robin Murphy
2025-10-02 13:01 ` Jason Gunthorpe [this message]
2025-10-01 9:16 ` Johan Hovold
2025-10-01 16:01 ` Jason Gunthorpe
2025-10-07 9:41 ` Johan Hovold
2025-10-02 12:17 ` Robin Murphy
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=20251002130116.GB3195829@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=angelogioacchino.delregno@collabora.com \
--cc=iommu@lists.linux.dev \
--cc=j@jannau.net \
--cc=johan@kernel.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=matthias.bgg@gmail.com \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=sven@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=vdumpa@nvidia.com \
--cc=wens@csie.org \
--cc=will@kernel.org \
--cc=yong.wu@mediatek.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®