From: Robin Murphy <robin.murphy@arm.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: 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, suravee.suthikulpanit@amd.com,
alyssa@rosenzweig.io, alim.akhtar@samsung.com,
dwmw2@infradead.org, yong.wu@mediatek.com,
mjrosato@linux.ibm.com, gerald.schaefer@linux.ibm.com,
thierry.reding@gmail.com, vdumpa@nvidia.com,
jonathanh@nvidia.com, cohuck@redhat.com,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [PATCH 2/5] iommu: Ensure device has the same iommu_ops as the domain
Date: Mon, 6 Jun 2022 18:50:33 +0100 [thread overview]
Message-ID: <6575de6d-94ba-c427-5b1e-967750ddff23@arm.com> (raw)
In-Reply-To: <Yp4wiJZWxoCLY8tm@Asurada-Nvidia>
On 2022-06-06 17:51, Nicolin Chen wrote:
> Hi Robin,
>
> On Mon, Jun 06, 2022 at 03:33:42PM +0100, Robin Murphy wrote:
>> 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.
>
> Do you have an alternative and less invasive solution in mind?
>
>>> 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 :/
>
> Will fix that.
Well, as before I'd prefer to make the code match the commit message -
if I really need to spell it out, see below - since I can't imagine that
we should ever have need to identify a set of iommu_domain_ops in
isolation, therefore I think it's considerably clearer to use the
iommu_domain itself. However, either way we really don't need this yet,
so we may as well just go ahead and remove the redundant test from VFIO
anyway, and I can add some form of this patch to my dev branch for now.
Thanks,
Robin.
----->8-----
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index cde2e1d6ab9b..72990edc9314 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1902,6 +1902,7 @@ static struct iommu_domain
*__iommu_domain_alloc(struct device *dev,
domain->type = type;
/* Assume all sizes by default; the driver may override this later */
domain->pgsize_bitmap = ops->pgsize_bitmap;
+ domain->owner = ops;
if (!domain->ops)
domain->ops = ops->default_domain_ops;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 6f64cbbc6721..79e557207f53 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -89,6 +89,7 @@ struct iommu_domain_geometry {
struct iommu_domain {
unsigned type;
+ const struct iommu_ops *owner; /* Who allocated this domain */
const struct iommu_domain_ops *ops;
unsigned long pgsize_bitmap; /* Bitmap of page sizes in use */
iommu_fault_handler_t handler;
next prev parent reply other threads:[~2022-06-06 17:50 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
2022-06-06 16:51 ` Nicolin Chen
2022-06-06 17:50 ` Robin Murphy [this message]
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=6575de6d-94ba-c427-5b1e-967750ddff23@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=vdumpa@nvidia.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).