From: Robin Murphy <robin.murphy@arm.com>
To: Nicolin Chen <nicolinc@nvidia.com>,
jgg@nvidia.com, joro@8bytes.org, will@kernel.org,
marcan@marcan.st, sven@svenpeter.dev, robdclark@gmail.com,
m.szyprowski@samsung.com, krzysztof.kozlowski@linaro.org,
baolu.lu@linux.intel.com, agross@kernel.org,
bjorn.andersson@linaro.org, matthias.bgg@gmail.com,
heiko@sntech.de, orsonzhai@gmail.com, baolin.wang7@gmail.com,
zhang.lyra@gmail.com, wens@csie.org, jernej.skrabec@gmail.com,
samuel@sholland.org, jean-philippe@linaro.org,
alex.williamson@redhat.com
Cc: mjrosato@linux.ibm.com,
virtualization@lists.linux-foundation.org,
thierry.reding@gmail.com, alim.akhtar@samsung.com,
alyssa@rosenzweig.io, linux-s390@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, kvm@vger.kernel.org,
jonathanh@nvidia.com, linux-rockchip@lists.infradead.org,
yong.wu@mediatek.com, gerald.schaefer@linux.ibm.com,
linux-sunxi@lists.linux.dev, linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, cohuck@redhat.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
suravee.suthikulpanit@amd.com, dwmw2@infradead.org
Subject: Re: [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain
Date: Mon, 6 Jun 2022 15:33:42 +0100 [thread overview]
Message-ID: <1e0e5403-1e65-db9a-c8e7-34e316bfda8e@arm.com> (raw)
In-Reply-To: <20220606061927.26049-3-nicolinc@nvidia.com>
On 2022-06-06 07:19, Nicolin Chen wrote:
> The core code should not call an iommu driver op with a struct device
> parameter unless it knows that the dev_iommu_priv_get() for that struct
> device was setup by the same driver. Otherwise in a mixed driver system
> the iommu_priv could be casted to the wrong type.
We don't have mixed-driver systems, and there are plenty more
significant problems than this one to solve before we can (but thanks
for pointing it out - I hadn't got as far as auditing the public
interfaces yet). Once domains are allocated via a particular device's
IOMMU instance in the first place, there will be ample opportunity for
the core to stash suitable identifying information in the domain for
itself. TBH even the current code could do it without needing the
weirdly invasive changes here.
> Store the iommu_ops pointer in the iommu_domain and use it as a check to
> validate that the struct device is correct before invoking any domain op
> that accepts a struct device.
In fact this even describes exactly that - "Store the iommu_ops pointer
in the iommu_domain", vs. the "Store the iommu_ops pointer in the
iommu_domain_ops" which the patch is actually doing :/
[...]
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 19cf28d40ebe..8a1f437a51f2 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1963,6 +1963,10 @@ static int __iommu_attach_device(struct iommu_domain *domain,
> {
> int ret;
>
> + /* Ensure the device was probe'd onto the same driver as the domain */
> + if (dev->bus->iommu_ops != domain->ops->iommu_ops)
Nope, dev_iommu_ops(dev) please. Furthermore I think the logical place
to put this is in iommu_group_do_attach_device(), since that's the
gateway for the public interfaces - we shouldn't need to second-guess
ourselves for internal default-domain-related calls.
Thanks,
Robin.
> + return -EMEDIUMTYPE;
> +
> if (unlikely(domain->ops->attach_dev == NULL))
> return -ENODEV;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-06 14:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-06 6:19 [PATCH 0/5] Simplify vfio_iommu_type1 attach/detach routine Nicolin Chen
2022-06-06 6:19 ` [PATCH 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain and device/group Nicolin Chen
2022-06-07 3:23 ` Baolu Lu
2022-06-07 4:03 ` Nicolin Chen
2022-06-08 7:49 ` Tian, Kevin
2022-06-08 17:38 ` Nicolin Chen
2022-06-06 6:19 ` [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain Nicolin Chen
2022-06-06 14:33 ` Robin Murphy [this message]
2022-06-06 16:51 ` Nicolin Chen
2022-06-06 17:50 ` Robin Murphy
2022-06-06 18:28 ` Nicolin Chen
2022-06-06 18:52 ` Jason Gunthorpe
2022-06-06 6:19 ` [PATCH 3/5] vfio/iommu_type1: Prefer to reuse domains vs match enforced cache coherency Nicolin Chen
2022-06-08 8:28 ` Tian, Kevin
2022-06-08 11:17 ` Jason Gunthorpe
2022-06-08 23:48 ` Tian, Kevin
2022-06-14 20:45 ` Nicolin Chen
2022-06-15 7:35 ` Tian, Kevin
2022-06-15 23:12 ` Nicolin Chen
2022-06-06 6:19 ` [PATCH 4/5] vfio/iommu_type1: Clean up update_dirty_scope in detach_group() Nicolin Chen
2022-06-08 8:35 ` Tian, Kevin
2022-06-08 17:46 ` Nicolin Chen
2022-06-06 6:19 ` [PATCH 5/5] vfio/iommu_type1: Simplify group attachment Nicolin Chen
2022-06-07 7:44 ` [PATCH 0/5] Simplify vfio_iommu_type1 attach/detach routine Baolu Lu
2022-06-07 11:58 ` Jason Gunthorpe
2022-06-07 12:42 ` 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=1e0e5403-1e65-db9a-c8e7-34e316bfda8e@arm.com \
--to=robin.murphy@arm.com \
--cc=agross@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=alim.akhtar@samsung.com \
--cc=alyssa@rosenzweig.io \
--cc=baolin.wang7@gmail.com \
--cc=baolu.lu@linux.intel.com \
--cc=bjorn.andersson@linaro.org \
--cc=cohuck@redhat.com \
--cc=dwmw2@infradead.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=jernej.skrabec@gmail.com \
--cc=jgg@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=marcan@marcan.st \
--cc=matthias.bgg@gmail.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=orsonzhai@gmail.com \
--cc=robdclark@gmail.com \
--cc=samuel@sholland.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=sven@svenpeter.dev \
--cc=thierry.reding@gmail.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=wens@csie.org \
--cc=will@kernel.org \
--cc=yong.wu@mediatek.com \
--cc=zhang.lyra@gmail.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;
as well as URLs for NNTP newsgroup(s).