* [PATCH 1/5] iommu/msm: Add missing __disable_clocks calls
2022-09-13 8:24 [PATCH 0/5] iommu: Define EINVAL as device/domain incompatibility Nicolin Chen
@ 2022-09-13 8:24 ` Nicolin Chen
2022-09-13 8:24 ` [PATCH 2/5] iommu/amd: Drop unnecessary checks in amd_iommu_attach_device() Nicolin Chen
` (3 subsequent siblings)
4 siblings, 0 replies; 15+ messages in thread
From: Nicolin Chen @ 2022-09-13 8:24 UTC (permalink / raw)
To: joro, suravee.suthikulpanit, will, robin.murphy, robdclark,
dwmw2, baolu.lu, agross, bjorn.andersson, konrad.dybcio,
matthias.bgg, heiko, orsonzhai, baolin.wang, zhang.lyra,
thierry.reding, jean-philippe, jgg, sricharan
Cc: linux-kernel, linux-arm-msm, yangyingliang, jon, iommu,
shameerali.kolothum.thodi, jonathanh, linux-rockchip,
christophe.jaillet, linux-arm-kernel, thunder.leizhen,
linux-tegra, linux-mediatek, tglx, virtualization, yong.wu
The clock is not symmetrically disabled in the error-out routines.
Fixes: 109bd48ea2e1 ("iommu/msm: Add DT adaptation")
Cc: stable@vger.kernel.org
Cc: Sricharan R <sricharan@codeaurora.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/msm_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 6a24aa804ea3..a7d41ba4a47b 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -418,6 +418,7 @@ static int msm_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
list_for_each_entry(master, &iommu->ctx_list, list) {
if (master->num) {
dev_err(dev, "domain already attached");
+ __disable_clocks(iommu);
ret = -EEXIST;
goto fail;
}
@@ -425,6 +426,7 @@ static int msm_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
msm_iommu_alloc_ctx(iommu->context_map,
0, iommu->ncb);
if (IS_ERR_VALUE(master->num)) {
+ __disable_clocks(iommu);
ret = -ENODEV;
goto fail;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 2/5] iommu/amd: Drop unnecessary checks in amd_iommu_attach_device()
2022-09-13 8:24 [PATCH 0/5] iommu: Define EINVAL as device/domain incompatibility Nicolin Chen
2022-09-13 8:24 ` [PATCH 1/5] iommu/msm: Add missing __disable_clocks calls Nicolin Chen
@ 2022-09-13 8:24 ` Nicolin Chen
2022-09-13 8:24 ` [PATCH 3/5] iommu: Add return errno rules to ->attach_dev ops Nicolin Chen
` (2 subsequent siblings)
4 siblings, 0 replies; 15+ messages in thread
From: Nicolin Chen @ 2022-09-13 8:24 UTC (permalink / raw)
To: joro, suravee.suthikulpanit, will, robin.murphy, robdclark,
dwmw2, baolu.lu, agross, bjorn.andersson, konrad.dybcio,
matthias.bgg, heiko, orsonzhai, baolin.wang, zhang.lyra,
thierry.reding, jean-philippe, jgg, sricharan
Cc: linux-kernel, linux-arm-msm, yangyingliang, jon, iommu,
shameerali.kolothum.thodi, jonathanh, linux-rockchip,
christophe.jaillet, linux-arm-kernel, thunder.leizhen,
linux-tegra, linux-mediatek, tglx, virtualization, yong.wu
The same checks are done in amd_iommu_probe_device(). If any of them fails
there, then the device won't get a group, so there's no way for it to even
reach amd_iommu_attach_device any more.
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/amd/iommu.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 828672a46a3d..930d9946b9f7 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2135,21 +2135,13 @@ static void amd_iommu_detach_device(struct iommu_domain *dom,
static int amd_iommu_attach_device(struct iommu_domain *dom,
struct device *dev)
{
+ struct iommu_dev_data *dev_data = dev_iommu_priv_get(dev);
struct protection_domain *domain = to_pdomain(dom);
- struct iommu_dev_data *dev_data;
- struct amd_iommu *iommu;
+ struct amd_iommu *iommu = rlookup_amd_iommu(dev);
int ret;
- if (!check_device(dev))
- return -EINVAL;
-
- dev_data = dev_iommu_priv_get(dev);
dev_data->defer_attach = false;
- iommu = rlookup_amd_iommu(dev);
- if (!iommu)
- return -EINVAL;
-
if (dev_data->domain)
detach_device(dev);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 3/5] iommu: Add return errno rules to ->attach_dev ops
2022-09-13 8:24 [PATCH 0/5] iommu: Define EINVAL as device/domain incompatibility Nicolin Chen
2022-09-13 8:24 ` [PATCH 1/5] iommu/msm: Add missing __disable_clocks calls Nicolin Chen
2022-09-13 8:24 ` [PATCH 2/5] iommu/amd: Drop unnecessary checks in amd_iommu_attach_device() Nicolin Chen
@ 2022-09-13 8:24 ` Nicolin Chen
2022-09-13 18:41 ` Jeff Johnson
2022-09-13 8:24 ` [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions Nicolin Chen
2022-09-13 8:24 ` [PATCH 5/5] iommu: Use EINVAL for incompatible device/domain in ->attach_dev Nicolin Chen
4 siblings, 1 reply; 15+ messages in thread
From: Nicolin Chen @ 2022-09-13 8:24 UTC (permalink / raw)
To: joro, suravee.suthikulpanit, will, robin.murphy, robdclark,
dwmw2, baolu.lu, agross, bjorn.andersson, konrad.dybcio,
matthias.bgg, heiko, orsonzhai, baolin.wang, zhang.lyra,
thierry.reding, jean-philippe, jgg, sricharan
Cc: linux-kernel, linux-arm-msm, yangyingliang, jon, iommu,
shameerali.kolothum.thodi, jonathanh, linux-rockchip,
christophe.jaillet, linux-arm-kernel, thunder.leizhen,
linux-tegra, linux-mediatek, tglx, virtualization, yong.wu
Cases like VFIO wish to attach a device to an existing domain that was
not allocated specifically from the device. This raises a condition
where the IOMMU driver can fail the domain attach because the domain and
device are incompatible with each other.
This is a soft failure that can be resolved by using a different domain.
Provide a dedicated errno EINVAL from the IOMMU driver during attach that
the reason attached failed is because of domain incompatability.
VFIO can use this to know attach is a soft failure and it should continue
searching. Otherwise the attach will be a hard failure and VFIO will
return the code to userspace.
Update kdocs first to add rules of return errno to ->attach_dev ops.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
include/linux/iommu.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index ea30f00dc145..c5d7ec0187c7 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -266,6 +266,17 @@ struct iommu_ops {
/**
* struct iommu_domain_ops - domain specific operations
* @attach_dev: attach an iommu domain to a device
+ * Rules of its return errno:
+ * EINVAL - Exclusively, device and domain are incompatible. Must
+ * avoid kernel prints along with this errno. Any EINVAL
+ * returned from kAPIs must be converted to ENODEV if it
+ * is device-specific, or to some other reasonable errno
+ * being listed below
+ * ENOMEM - Out of memory
+ * ENOSPC - No space left on device
+ * EBUSY - Device is attached to a domain and cannot be changed
+ * ENODEV - Device specific errors, not able to be attached
+ * <others> - Treated as ENODEV by the caller. Use is discouraged
* @detach_dev: detach an iommu domain from a device
* @map: map a physically contiguous memory region to an iommu domain
* @map_pages: map a physically contiguous set of pages of the same size to
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 3/5] iommu: Add return errno rules to ->attach_dev ops
2022-09-13 8:24 ` [PATCH 3/5] iommu: Add return errno rules to ->attach_dev ops Nicolin Chen
@ 2022-09-13 18:41 ` Jeff Johnson
2022-09-13 20:00 ` Nicolin Chen
0 siblings, 1 reply; 15+ messages in thread
From: Jeff Johnson @ 2022-09-13 18:41 UTC (permalink / raw)
To: Nicolin Chen, joro, suravee.suthikulpanit, will, robin.murphy,
robdclark, dwmw2, baolu.lu, agross, bjorn.andersson,
konrad.dybcio, matthias.bgg, heiko, orsonzhai, baolin.wang,
zhang.lyra, thierry.reding, jean-philippe, jgg, sricharan
Cc: linux-kernel, linux-arm-msm, yangyingliang, jon, iommu,
shameerali.kolothum.thodi, jonathanh, linux-rockchip,
christophe.jaillet, linux-arm-kernel, thunder.leizhen,
linux-tegra, linux-mediatek, tglx, virtualization, yong.wu
On 9/13/2022 1:24 AM, Nicolin Chen wrote:
> Cases like VFIO wish to attach a device to an existing domain that was
> not allocated specifically from the device. This raises a condition
> where the IOMMU driver can fail the domain attach because the domain and
> device are incompatible with each other.
>
> This is a soft failure that can be resolved by using a different domain.
>
> Provide a dedicated errno EINVAL from the IOMMU driver during attach that
> the reason attached failed is because of domain incompatability.
>
> VFIO can use this to know attach is a soft failure and it should continue
> searching. Otherwise the attach will be a hard failure and VFIO will
> return the code to userspace.
>
> Update kdocs first to add rules of return errno to ->attach_dev ops.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> include/linux/iommu.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index ea30f00dc145..c5d7ec0187c7 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -266,6 +266,17 @@ struct iommu_ops {
> /**
> * struct iommu_domain_ops - domain specific operations
> * @attach_dev: attach an iommu domain to a device
> + * Rules of its return errno:
> + * EINVAL - Exclusively, device and domain are incompatible. Must
> + * avoid kernel prints along with this errno. Any EINVAL
> + * returned from kAPIs must be converted to ENODEV if it
> + * is device-specific, or to some other reasonable errno
> + * being listed below
> + * ENOMEM - Out of memory
> + * ENOSPC - No space left on device
> + * EBUSY - Device is attached to a domain and cannot be changed
> + * ENODEV - Device specific errors, not able to be attached
> + * <others> - Treated as ENODEV by the caller. Use is discouraged
It is my understanding that kernel-doc won't preserve your formatting
without extra directives. See the "Note" after
<https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#return-values>
> * @detach_dev: detach an iommu domain from a device
> * @map: map a physically contiguous memory region to an iommu domain
> * @map_pages: map a physically contiguous set of pages of the same size to
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 3/5] iommu: Add return errno rules to ->attach_dev ops
2022-09-13 18:41 ` Jeff Johnson
@ 2022-09-13 20:00 ` Nicolin Chen
0 siblings, 0 replies; 15+ messages in thread
From: Nicolin Chen @ 2022-09-13 20:00 UTC (permalink / raw)
To: Jeff Johnson
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, jean-philippe, zhang.lyra, joro, jon,
jonathanh, linux-rockchip, iommu, agross, linux-arm-kernel, jgg,
yangyingliang, orsonzhai, linux-arm-msm, robin.murphy,
christophe.jaillet, baolin.wang, thunder.leizhen, matthias.bgg,
tglx, virtualization, yong.wu, dwmw2, linux-kernel,
shameerali.kolothum.thodi, robdclark, suravee.suthikulpanit,
linux-mediatek, sricharan, baolu.lu
Hi Jeff,
On Tue, Sep 13, 2022 at 11:41:35AM -0700, Jeff Johnson wrote:
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index ea30f00dc145..c5d7ec0187c7 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -266,6 +266,17 @@ struct iommu_ops {
> > /**
> > * struct iommu_domain_ops - domain specific operations
> > * @attach_dev: attach an iommu domain to a device
> > + * Rules of its return errno:
> > + * EINVAL - Exclusively, device and domain are incompatible. Must
> > + * avoid kernel prints along with this errno. Any EINVAL
> > + * returned from kAPIs must be converted to ENODEV if it
> > + * is device-specific, or to some other reasonable errno
> > + * being listed below
> > + * ENOMEM - Out of memory
> > + * ENOSPC - No space left on device
> > + * EBUSY - Device is attached to a domain and cannot be changed
> > + * ENODEV - Device specific errors, not able to be attached
> > + * <others> - Treated as ENODEV by the caller. Use is discouraged
>
> It is my understanding that kernel-doc won't preserve your formatting
> without extra directives. See the "Note" after
> <https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#return-values>
Thanks for the review!
Perhaps the following one would work:
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index ea30f00dc145..14f078b58e17 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -266,6 +266,17 @@ struct iommu_ops {
/**
* struct iommu_domain_ops - domain specific operations
* @attach_dev: attach an iommu domain to a device
+ * Return:
+ * * 0 - success
+ * * EINVAL - Exclusively, device and domain are incompatible. Must avoid
+ * kernel prints along with this errno. Any EINVAL returned from
+ * a kAPI must be converted to ENODEV if it is device-specific,
+ * or to some other reasonable errno being listed below
+ * * ENOMEM - Out of memory
+ * * ENOSPC - No space left on device
+ * * EBUSY - Device is attached to a domain and cannot be changed
+ * * ENODEV - Device specific errors, not able to be attached
+ * * <others> - Treated as ENODEV by the caller. Use is discouraged
* @detach_dev: detach an iommu domain from a device
* @map: map a physically contiguous memory region to an iommu domain
* @map_pages: map a physically contiguous set of pages of the same size to
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-13 8:24 [PATCH 0/5] iommu: Define EINVAL as device/domain incompatibility Nicolin Chen
` (2 preceding siblings ...)
2022-09-13 8:24 ` [PATCH 3/5] iommu: Add return errno rules to ->attach_dev ops Nicolin Chen
@ 2022-09-13 8:24 ` Nicolin Chen
2022-09-13 12:27 ` Jean-Philippe Brucker
2022-09-13 8:24 ` [PATCH 5/5] iommu: Use EINVAL for incompatible device/domain in ->attach_dev Nicolin Chen
4 siblings, 1 reply; 15+ messages in thread
From: Nicolin Chen @ 2022-09-13 8:24 UTC (permalink / raw)
To: joro, suravee.suthikulpanit, will, robin.murphy, robdclark,
dwmw2, baolu.lu, agross, bjorn.andersson, konrad.dybcio,
matthias.bgg, heiko, orsonzhai, baolin.wang, zhang.lyra,
thierry.reding, jean-philippe, jgg, sricharan
Cc: linux-kernel, linux-arm-msm, yangyingliang, jon, iommu,
shameerali.kolothum.thodi, jonathanh, linux-rockchip,
christophe.jaillet, linux-arm-kernel, thunder.leizhen,
linux-tegra, linux-mediatek, tglx, virtualization, yong.wu
Following the new rules in include/linux/iommu.h kdocs, update all drivers
->attach_dev callback functions to return ENODEV error code for all device
specific errors. It particularly excludes EINVAL from being used for such
error cases. For the same purpose, also replace one EINVAL with ENOMEM in
mtk_iommu driver.
Note that the virtio-iommu does a viommu_domain_map_identity() call, which
returns either 0 or ENOMEM at this moment. Change to "return ret" directly
to allow it to pass an EINVAL in the future.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +-
drivers/iommu/arm/arm-smmu/arm-smmu.c | 4 ++--
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 2 +-
drivers/iommu/fsl_pamu.c | 6 +++---
drivers/iommu/fsl_pamu_domain.c | 4 ++--
drivers/iommu/intel/pasid.c | 2 +-
drivers/iommu/ipmmu-vmsa.c | 2 +-
drivers/iommu/mtk_iommu.c | 9 ++++++---
drivers/iommu/omap-iommu.c | 4 ++--
drivers/iommu/rockchip-iommu.c | 4 +++-
drivers/iommu/tegra-smmu.c | 2 +-
drivers/iommu/virtio-iommu.c | 2 +-
12 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index d32b02336411..0186dfdf31fe 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2402,7 +2402,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
struct arm_smmu_master *master;
if (!fwspec)
- return -ENOENT;
+ return -ENODEV;
master = dev_iommu_priv_get(dev);
smmu = master->smmu;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index dfa82df00342..771dd161545c 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1137,7 +1137,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
if (!fwspec || fwspec->ops != &arm_smmu_ops) {
dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n");
- return -ENXIO;
+ return -ENODEV;
}
/*
@@ -1155,7 +1155,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
ret = arm_smmu_rpm_get(smmu);
if (ret < 0)
- return ret;
+ return -ENODEV;
/* Ensure that the domain is finalised */
ret = arm_smmu_init_domain_context(domain, smmu, dev);
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index 17235116d3bb..49d40c80afd3 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -367,7 +367,7 @@ static int qcom_iommu_attach_dev(struct iommu_domain *domain, struct device *dev
if (!qcom_iommu) {
dev_err(dev, "cannot attach to IOMMU, is it on the same bus?\n");
- return -ENXIO;
+ return -ENODEV;
}
/* Ensure that the domain is finalized */
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index 0d03f837a5d4..021ab3f9e6d2 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -126,7 +126,7 @@ int pamu_disable_liodn(int liodn)
ppaace = pamu_get_ppaace(liodn);
if (!ppaace) {
pr_debug("Invalid primary paace entry\n");
- return -ENOENT;
+ return -ENODEV;
}
set_bf(ppaace->addr_bitfields, PAACE_AF_V, PAACE_V_INVALID);
@@ -194,7 +194,7 @@ int pamu_config_ppaace(int liodn, u32 omi, u32 stashid, int prot)
ppaace = pamu_get_ppaace(liodn);
if (!ppaace)
- return -ENOENT;
+ return -ENODEV;
/* window size is 2^(WSE+1) bytes */
set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE,
@@ -211,7 +211,7 @@ int pamu_config_ppaace(int liodn, u32 omi, u32 stashid, int prot)
ppaace->op_encode.index_ot.omi = omi;
} else if (~omi != 0) {
pr_debug("bad operation mapping index: %d\n", omi);
- return -EINVAL;
+ return -ENODEV;
}
/* configure stash id */
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 011f9ab7f743..b4a1c0f79c3e 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -258,7 +258,7 @@ static int fsl_pamu_attach_device(struct iommu_domain *domain,
liodn = of_get_property(dev->of_node, "fsl,liodn", &len);
if (!liodn) {
pr_debug("missing fsl,liodn property at %pOF\n", dev->of_node);
- return -EINVAL;
+ return -ENODEV;
}
spin_lock_irqsave(&dma_domain->domain_lock, flags);
@@ -267,7 +267,7 @@ static int fsl_pamu_attach_device(struct iommu_domain *domain,
if (liodn[i] >= PAACE_NUMBER_ENTRIES) {
pr_debug("Invalid liodn %d, attach device failed for %pOF\n",
liodn[i], dev->of_node);
- ret = -EINVAL;
+ ret = -ENODEV;
break;
}
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
index c5e7e8b020a5..712c7f3960e5 100644
--- a/drivers/iommu/intel/pasid.c
+++ b/drivers/iommu/intel/pasid.c
@@ -102,7 +102,7 @@ int intel_pasid_alloc_table(struct device *dev)
might_sleep();
info = dev_iommu_priv_get(dev);
if (WARN_ON(!info || !dev_is_pci(dev) || info->pasid_table))
- return -EINVAL;
+ return -ENODEV;
pasid_table = kzalloc(sizeof(*pasid_table), GFP_KERNEL);
if (!pasid_table)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 1d42084d0276..cb14abcfa43a 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -607,7 +607,7 @@ static int ipmmu_attach_device(struct iommu_domain *io_domain,
if (!mmu) {
dev_err(dev, "Cannot attach to IPMMU\n");
- return -ENXIO;
+ return -ENODEV;
}
mutex_lock(&domain->mutex);
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 7e363b1f24df..dcfe728a4526 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -562,10 +562,12 @@ static int mtk_iommu_config(struct mtk_iommu_data *data, struct device *dev,
peri_mmuen = enable ? peri_mmuen_msk : 0;
ret = regmap_update_bits(data->pericfg, PERICFG_IOMMU_1,
peri_mmuen_msk, peri_mmuen);
- if (ret)
+ if (ret) {
dev_err(dev, "%s iommu(%s) inframaster 0x%x fail(%d).\n",
enable ? "enable" : "disable",
dev_name(data->dev), peri_mmuen_msk, ret);
+ ret = -ENODEV;
+ }
}
}
return ret;
@@ -607,7 +609,7 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom,
dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
if (!dom->iop) {
dev_err(data->dev, "Failed to alloc io pgtable\n");
- return -EINVAL;
+ return -ENOMEM;
}
/* Update our support page sizes bitmap */
@@ -655,7 +657,7 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
region_id = mtk_iommu_get_iova_region_id(dev, data->plat_data);
if (region_id < 0)
- return region_id;
+ return -ENODEV;
bankid = mtk_iommu_get_bank_id(dev, data->plat_data);
mutex_lock(&dom->mutex);
@@ -678,6 +680,7 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
ret = pm_runtime_resume_and_get(m4udev);
if (ret < 0) {
dev_err(m4udev, "pm get fail(%d) in attach.\n", ret);
+ ret = -ENODEV;
goto err_unlock;
}
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d9cf2820c02e..447e40d55918 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1414,7 +1414,7 @@ static int omap_iommu_attach_init(struct device *dev,
odomain->num_iommus = omap_iommu_count(dev);
if (!odomain->num_iommus)
- return -EINVAL;
+ return -ENODEV;
odomain->iommus = kcalloc(odomain->num_iommus, sizeof(*iommu),
GFP_ATOMIC);
@@ -1464,7 +1464,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
if (!arch_data || !arch_data->iommu_dev) {
dev_err(dev, "device doesn't have an associated iommu\n");
- return -EINVAL;
+ return -ENODEV;
}
spin_lock(&omap_domain->lock);
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index ab57c4b8fade..de483b5532ed 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1051,8 +1051,10 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
return 0;
ret = rk_iommu_enable(iommu);
- if (ret)
+ if (ret) {
rk_iommu_detach_device(iommu->domain, dev);
+ ret = -ENODEV;
+ }
pm_runtime_put(iommu->dev);
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 2a8de975fe63..093c10db4cb4 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -487,7 +487,7 @@ static int tegra_smmu_attach_dev(struct iommu_domain *domain,
int err;
if (!fwspec)
- return -ENOENT;
+ return -ENODEV;
for (index = 0; index < fwspec->num_ids; index++) {
err = tegra_smmu_as_prepare(smmu, as);
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 80151176ba12..874c01634d2b 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -696,7 +696,7 @@ static int viommu_domain_finalise(struct viommu_endpoint *vdev,
if (ret) {
ida_free(&viommu->domain_ids, vdomain->id);
vdomain->viommu = NULL;
- return -EOPNOTSUPP;
+ return ret;
}
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-13 8:24 ` [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions Nicolin Chen
@ 2022-09-13 12:27 ` Jean-Philippe Brucker
2022-09-13 20:14 ` Nicolin Chen
2022-09-14 9:11 ` Jason Gunthorpe
0 siblings, 2 replies; 15+ messages in thread
From: Jean-Philippe Brucker @ 2022-09-13 12:27 UTC (permalink / raw)
To: Nicolin Chen
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, zhang.lyra, joro, jon, jonathanh,
linux-rockchip, iommu, agross, linux-arm-kernel, jgg,
yangyingliang, orsonzhai, linux-arm-msm, robin.murphy,
christophe.jaillet, baolin.wang, thunder.leizhen, matthias.bgg,
tglx, virtualization, yong.wu, dwmw2, linux-kernel,
shameerali.kolothum.thodi, robdclark, suravee.suthikulpanit,
linux-mediatek, sricharan, baolu.lu
Hi Nicolin,
On Tue, Sep 13, 2022 at 01:24:47AM -0700, Nicolin Chen wrote:
> Following the new rules in include/linux/iommu.h kdocs, update all drivers
> ->attach_dev callback functions to return ENODEV error code for all device
> specific errors. It particularly excludes EINVAL from being used for such
> error cases. For the same purpose, also replace one EINVAL with ENOMEM in
> mtk_iommu driver.
>
> Note that the virtio-iommu does a viommu_domain_map_identity() call, which
> returns either 0 or ENOMEM at this moment. Change to "return ret" directly
> to allow it to pass an EINVAL in the future.
[...]
> diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> index 80151176ba12..874c01634d2b 100644
> --- a/drivers/iommu/virtio-iommu.c
> +++ b/drivers/iommu/virtio-iommu.c
> @@ -696,7 +696,7 @@ static int viommu_domain_finalise(struct viommu_endpoint *vdev,
> if (ret) {
> ida_free(&viommu->domain_ids, vdomain->id);
> vdomain->viommu = NULL;
> - return -EOPNOTSUPP;
> + return ret;
I think in the future it will be too easy to forget about the constrained
return value of attach() while modifying some other part of the driver,
and let an external helper return EINVAL. So I'd rather not propagate ret
from outside of viommu_domain_attach() and finalise().
For the same reason I do prefer this solution over EMEDIUMTYPE, because
it's too tempting to use exotic errno when they seem appropriate instead
of boring ENODEV and EINVAL. The alternative would be adding a special
purpose code to linux/errno.h, similarly to EPROBE_DEFER, but that might
be excessive.
Since we can't guarantee that APIs like virtio or ida won't ever return
EINVAL, we should set all return values:
--- 8< ---
From 7b16796cb78d11971236f98fd2d3cd73ca769827 Mon Sep 17 00:00:00 2001
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
Date: Tue, 13 Sep 2022 12:53:02 +0100
Subject: [PATCH] iommu/virtio: Constrain return value of viommu_attach_dev()
Ensure viommu_attach_dev() only return errno values expected from the
attach_dev() op. In particular, only return EINVAL when we're sure that
the device is incompatible with the domain.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/virtio-iommu.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 08eeafc9529f..582ff5a33b52 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -669,13 +669,13 @@ static int viommu_domain_finalise(struct viommu_endpoint *vdev,
dev_err(vdev->dev,
"granule 0x%lx larger than system page size 0x%lx\n",
viommu_page_size, PAGE_SIZE);
- return -EINVAL;
+ return -ENODEV;
}
ret = ida_alloc_range(&viommu->domain_ids, viommu->first_domain,
viommu->last_domain, GFP_KERNEL);
if (ret < 0)
- return ret;
+ return -ENOMEM;
vdomain->id = (unsigned int)ret;
@@ -696,7 +696,7 @@ static int viommu_domain_finalise(struct viommu_endpoint *vdev,
if (ret) {
ida_free(&viommu->domain_ids, vdomain->id);
vdomain->viommu = NULL;
- return -EOPNOTSUPP;
+ return -ENODEV;
}
}
@@ -734,7 +734,7 @@ static int viommu_attach_dev(struct iommu_domain *domain, struct device *dev)
ret = viommu_domain_finalise(vdev, domain);
} else if (vdomain->viommu != vdev->viommu) {
dev_err(dev, "cannot attach to foreign vIOMMU\n");
- ret = -EXDEV;
+ ret = -EINVAL;
}
mutex_unlock(&vdomain->mutex);
@@ -769,7 +769,7 @@ static int viommu_attach_dev(struct iommu_domain *domain, struct device *dev)
ret = viommu_send_req_sync(vdomain->viommu, &req, sizeof(req));
if (ret)
- return ret;
+ return -ENODEV;
}
if (!vdomain->nr_endpoints) {
@@ -779,7 +779,7 @@ static int viommu_attach_dev(struct iommu_domain *domain, struct device *dev)
*/
ret = viommu_replay_mappings(vdomain);
if (ret)
- return ret;
+ return -ENODEV;
}
vdomain->nr_endpoints++;
--
2.37.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-13 12:27 ` Jean-Philippe Brucker
@ 2022-09-13 20:14 ` Nicolin Chen
2022-09-14 9:11 ` Jason Gunthorpe
1 sibling, 0 replies; 15+ messages in thread
From: Nicolin Chen @ 2022-09-13 20:14 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, zhang.lyra, joro, jon, jonathanh,
linux-rockchip, iommu, agross, linux-arm-kernel, jgg,
yangyingliang, orsonzhai, linux-arm-msm, robin.murphy,
christophe.jaillet, baolin.wang, thunder.leizhen, matthias.bgg,
tglx, virtualization, yong.wu, dwmw2, linux-kernel,
shameerali.kolothum.thodi, robdclark, suravee.suthikulpanit,
linux-mediatek, sricharan, baolu.lu
Hi Jean,
On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote:
> External email: Use caution opening links or attachments
>
>
> Hi Nicolin,
>
> On Tue, Sep 13, 2022 at 01:24:47AM -0700, Nicolin Chen wrote:
> > Following the new rules in include/linux/iommu.h kdocs, update all drivers
> > ->attach_dev callback functions to return ENODEV error code for all device
> > specific errors. It particularly excludes EINVAL from being used for such
> > error cases. For the same purpose, also replace one EINVAL with ENOMEM in
> > mtk_iommu driver.
> >
> > Note that the virtio-iommu does a viommu_domain_map_identity() call, which
> > returns either 0 or ENOMEM at this moment. Change to "return ret" directly
> > to allow it to pass an EINVAL in the future.
> [...]
> > diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
> > index 80151176ba12..874c01634d2b 100644
> > --- a/drivers/iommu/virtio-iommu.c
> > +++ b/drivers/iommu/virtio-iommu.c
> > @@ -696,7 +696,7 @@ static int viommu_domain_finalise(struct viommu_endpoint *vdev,
> > if (ret) {
> > ida_free(&viommu->domain_ids, vdomain->id);
> > vdomain->viommu = NULL;
> > - return -EOPNOTSUPP;
> > + return ret;
>
> I think in the future it will be too easy to forget about the constrained
> return value of attach() while modifying some other part of the driver,
> and let an external helper return EINVAL. So I'd rather not propagate ret
> from outside of viommu_domain_attach() and finalise().
>
> For the same reason I do prefer this solution over EMEDIUMTYPE, because
> it's too tempting to use exotic errno when they seem appropriate instead
> of boring ENODEV and EINVAL. The alternative would be adding a special
> purpose code to linux/errno.h, similarly to EPROBE_DEFER, but that might
> be excessive.
>
> Since we can't guarantee that APIs like virtio or ida won't ever return
> EINVAL, we should set all return values:
Thanks for the inputs. Assuming your attached patch isn't officially
sent, I will group it into my next version.
Similarly, I will also double check other drivers, to make sure all
of them have explicit return values, other than "ret".
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-13 12:27 ` Jean-Philippe Brucker
2022-09-13 20:14 ` Nicolin Chen
@ 2022-09-14 9:11 ` Jason Gunthorpe
2022-09-14 9:49 ` Jean-Philippe Brucker
1 sibling, 1 reply; 15+ messages in thread
From: Jason Gunthorpe @ 2022-09-14 9:11 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, zhang.lyra, joro, jon, jonathanh,
linux-rockchip, iommu, agross, Nicolin Chen, linux-arm-kernel,
yangyingliang, orsonzhai, dwmw2, linux-arm-msm,
christophe.jaillet, baolin.wang, thunder.leizhen, matthias.bgg,
tglx, virtualization, yong.wu, robin.murphy, linux-kernel,
shameerali.kolothum.thodi, robdclark, suravee.suthikulpanit,
linux-mediatek, sricharan, baolu.lu
On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote:
> I think in the future it will be too easy to forget about the constrained
> return value of attach() while modifying some other part of the driver,
> and let an external helper return EINVAL. So I'd rather not propagate ret
> from outside of viommu_domain_attach() and finalise().
Fortunately, if -EINVAL is wrongly returned it only creates an
inefficiency, not a functional problem. So we do not need to be
precise here.
> Since we can't guarantee that APIs like virtio or ida won't ever return
> EINVAL, we should set all return values:
I dislike this alot, it squashes all return codes to try to optimize
an obscure failure path :(
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-14 9:11 ` Jason Gunthorpe
@ 2022-09-14 9:49 ` Jean-Philippe Brucker
2022-09-14 17:58 ` Nicolin Chen
0 siblings, 1 reply; 15+ messages in thread
From: Jean-Philippe Brucker @ 2022-09-14 9:49 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, zhang.lyra, joro, jon, jonathanh,
linux-rockchip, iommu, agross, Nicolin Chen, linux-arm-kernel,
yangyingliang, orsonzhai, dwmw2, linux-arm-msm,
christophe.jaillet, baolin.wang, thunder.leizhen, matthias.bgg,
tglx, virtualization, yong.wu, robin.murphy, linux-kernel,
shameerali.kolothum.thodi, robdclark, suravee.suthikulpanit,
linux-mediatek, sricharan, baolu.lu
On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote:
> > I think in the future it will be too easy to forget about the constrained
> > return value of attach() while modifying some other part of the driver,
> > and let an external helper return EINVAL. So I'd rather not propagate ret
> > from outside of viommu_domain_attach() and finalise().
>
> Fortunately, if -EINVAL is wrongly returned it only creates an
> inefficiency, not a functional problem. So we do not need to be
> precise here.
Ah fair. In that case the attach_dev() documentation should indicate that
EINVAL is a hint, so that callers don't rely on it (currently words "must"
and "exclusively" indicate that returning EINVAL for anything other than
device-domain incompatibility is unacceptable). The virtio-iommu
implementation may well return EINVAL from the virtio stack or from the
host response.
Thanks,
Jean
>
> > Since we can't guarantee that APIs like virtio or ida won't ever return
> > EINVAL, we should set all return values:
>
> I dislike this alot, it squashes all return codes to try to optimize
> an obscure failure path :(
>
> Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-14 9:49 ` Jean-Philippe Brucker
@ 2022-09-14 17:58 ` Nicolin Chen
2022-09-14 19:53 ` Robin Murphy
0 siblings, 1 reply; 15+ messages in thread
From: Nicolin Chen @ 2022-09-14 17:58 UTC (permalink / raw)
To: Jason Gunthorpe, Jean-Philippe Brucker
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, zhang.lyra, joro, jon, jonathanh,
linux-rockchip, iommu, agross, linux-arm-kernel, yangyingliang,
orsonzhai, linux-arm-msm, robin.murphy, christophe.jaillet,
baolin.wang, thunder.leizhen, matthias.bgg, tglx, virtualization,
yong.wu, dwmw2, linux-kernel, shameerali.kolothum.thodi,
robdclark, suravee.suthikulpanit, linux-mediatek, sricharan,
baolu.lu
On Wed, Sep 14, 2022 at 10:49:42AM +0100, Jean-Philippe Brucker wrote:
> External email: Use caution opening links or attachments
>
>
> On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote:
> > > I think in the future it will be too easy to forget about the constrained
> > > return value of attach() while modifying some other part of the driver,
> > > and let an external helper return EINVAL. So I'd rather not propagate ret
> > > from outside of viommu_domain_attach() and finalise().
> >
> > Fortunately, if -EINVAL is wrongly returned it only creates an
> > inefficiency, not a functional problem. So we do not need to be
> > precise here.
>
> Ah fair. In that case the attach_dev() documentation should indicate that
> EINVAL is a hint, so that callers don't rely on it (currently words "must"
> and "exclusively" indicate that returning EINVAL for anything other than
> device-domain incompatibility is unacceptable). The virtio-iommu
> implementation may well return EINVAL from the virtio stack or from the
> host response.
How about this?
+ * * EINVAL - mainly, device and domain are incompatible, or something went
+ * wrong with the domain. It's suggested to avoid kernel prints
+ * along with this errno. And it's better to convert any EINVAL
+ * returned from kAPIs to ENODEV if it is device-specific, or to
+ * some other reasonable errno being listed below
> > > Since we can't guarantee that APIs like virtio or ida won't ever return
> > > EINVAL, we should set all return values:
> >
> > I dislike this alot, it squashes all return codes to try to optimize
> > an obscure failure path :(
Hmm...should I revert all the driver changes back to this version?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-14 17:58 ` Nicolin Chen
@ 2022-09-14 19:53 ` Robin Murphy
2022-09-14 20:55 ` Nicolin Chen
0 siblings, 1 reply; 15+ messages in thread
From: Robin Murphy @ 2022-09-14 19:53 UTC (permalink / raw)
To: Nicolin Chen, Jason Gunthorpe, Jean-Philippe Brucker
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, zhang.lyra, joro, jon, jonathanh,
linux-rockchip, iommu, agross, linux-arm-kernel, yangyingliang,
orsonzhai, linux-arm-msm, christophe.jaillet, baolin.wang,
thunder.leizhen, matthias.bgg, tglx, virtualization, yong.wu,
dwmw2, linux-kernel, shameerali.kolothum.thodi, robdclark,
suravee.suthikulpanit, linux-mediatek, sricharan, baolu.lu
On 2022-09-14 18:58, Nicolin Chen wrote:
> On Wed, Sep 14, 2022 at 10:49:42AM +0100, Jean-Philippe Brucker wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote:
>>> On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote:
>>>> I think in the future it will be too easy to forget about the constrained
>>>> return value of attach() while modifying some other part of the driver,
>>>> and let an external helper return EINVAL. So I'd rather not propagate ret
>>>> from outside of viommu_domain_attach() and finalise().
>>>
>>> Fortunately, if -EINVAL is wrongly returned it only creates an
>>> inefficiency, not a functional problem. So we do not need to be
>>> precise here.
>>
>> Ah fair. In that case the attach_dev() documentation should indicate that
>> EINVAL is a hint, so that callers don't rely on it (currently words "must"
>> and "exclusively" indicate that returning EINVAL for anything other than
>> device-domain incompatibility is unacceptable). The virtio-iommu
>> implementation may well return EINVAL from the virtio stack or from the
>> host response.
>
> How about this?
>
> + * * EINVAL - mainly, device and domain are incompatible, or something went
> + * wrong with the domain. It's suggested to avoid kernel prints
> + * along with this errno. And it's better to convert any EINVAL
> + * returned from kAPIs to ENODEV if it is device-specific, or to
> + * some other reasonable errno being listed below
FWIW, I'd say something like:
"The device and domain are incompatible. If this is due to some previous
configuration of the domain, drivers should not log an error, since it
is legitimate for callers to test reuse of an existing domain.
Otherwise, it may still represent some fundamental problem."
And then at the public interfaces state it from other angle:
"The device and domain are incompatible. If the domain has already been
used or configured in some way, attaching the same device to a different
domain may be expected to succeed. Otherwise, it may still represent
some fundamental problem."
[ and to save another mail, I'm not sure copying the default comment for
ENOSPC is all that helpful either - what is "space" for something that
isn't a storage device? I'd guess limited hardware resources in some
form, but in the IOMMU context, potential confusion with address space
is maybe a little too close for comfort? ]
>>>> Since we can't guarantee that APIs like virtio or ida won't ever return
>>>> EINVAL, we should set all return values:
>>>
>>> I dislike this alot, it squashes all return codes to try to optimize
>>> an obscure failure path :(
>
> Hmm...should I revert all the driver changes back to this version?
Yeah, I don't think we need to go too mad here. Drivers shouldn't emit
their *own* -EINVAL unless appropriate, but if it comes back from some
external API then that implies something's gone unexpectedly wrong
anyway - maybe it's a transient condition and a subsequent different
attach might actually work out OK? We can't really say in general.
Besides, if the driver sees an error which implies it's done something
wrong itself, it probably shouldn't be trusted to try to reason about it
further. The caller can handle any error as long as we set their
expectations correctly.
Thanks,
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions
2022-09-14 19:53 ` Robin Murphy
@ 2022-09-14 20:55 ` Nicolin Chen
0 siblings, 0 replies; 15+ messages in thread
From: Nicolin Chen @ 2022-09-14 20:55 UTC (permalink / raw)
To: Robin Murphy
Cc: heiko, konrad.dybcio, bjorn.andersson, linux-tegra,
thierry.reding, will, Jean-Philippe Brucker, zhang.lyra, joro,
jon, jonathanh, linux-rockchip, iommu, agross, linux-arm-kernel,
Jason Gunthorpe, yangyingliang, orsonzhai, linux-arm-msm,
christophe.jaillet, baolin.wang, thunder.leizhen, matthias.bgg,
tglx, virtualization, yong.wu, dwmw2, linux-kernel,
shameerali.kolothum.thodi, robdclark, suravee.suthikulpanit,
linux-mediatek, sricharan, baolu.lu
Hi Robin,
On Wed, Sep 14, 2022 at 08:53:07PM +0100, Robin Murphy wrote:
> External email: Use caution opening links or attachments
>
>
> On 2022-09-14 18:58, Nicolin Chen wrote:
> > On Wed, Sep 14, 2022 at 10:49:42AM +0100, Jean-Philippe Brucker wrote:
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote:
> > > > On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote:
> > > > > I think in the future it will be too easy to forget about the constrained
> > > > > return value of attach() while modifying some other part of the driver,
> > > > > and let an external helper return EINVAL. So I'd rather not propagate ret
> > > > > from outside of viommu_domain_attach() and finalise().
> > > >
> > > > Fortunately, if -EINVAL is wrongly returned it only creates an
> > > > inefficiency, not a functional problem. So we do not need to be
> > > > precise here.
> > >
> > > Ah fair. In that case the attach_dev() documentation should indicate that
> > > EINVAL is a hint, so that callers don't rely on it (currently words "must"
> > > and "exclusively" indicate that returning EINVAL for anything other than
> > > device-domain incompatibility is unacceptable). The virtio-iommu
> > > implementation may well return EINVAL from the virtio stack or from the
> > > host response.
> >
> > How about this?
> >
> > + * * EINVAL - mainly, device and domain are incompatible, or something went
> > + * wrong with the domain. It's suggested to avoid kernel prints
> > + * along with this errno. And it's better to convert any EINVAL
> > + * returned from kAPIs to ENODEV if it is device-specific, or to
> > + * some other reasonable errno being listed below
>
> FWIW, I'd say something like:
>
> "The device and domain are incompatible. If this is due to some previous
> configuration of the domain, drivers should not log an error, since it
> is legitimate for callers to test reuse of an existing domain.
> Otherwise, it may still represent some fundamental problem."
OK. I will use this narrative.
> And then at the public interfaces state it from other angle:
>
> "The device and domain are incompatible. If the domain has already been
> used or configured in some way, attaching the same device to a different
> domain may be expected to succeed. Otherwise, it may still represent
> some fundamental problem."
I assume this should go to kdocs of iommu_attach_device/group().
> [ and to save another mail, I'm not sure copying the default comment for
> ENOSPC is all that helpful either - what is "space" for something that
> isn't a storage device? I'd guess limited hardware resources in some
> form, but in the IOMMU context, potential confusion with address space
> is maybe a little too close for comfort? ]
How about "non-ENOMEM type of resource allocation failure"?
> > > > > Since we can't guarantee that APIs like virtio or ida won't ever return
> > > > > EINVAL, we should set all return values:
> > > >
> > > > I dislike this alot, it squashes all return codes to try to optimize
> > > > an obscure failure path :(
> >
> > Hmm...should I revert all the driver changes back to this version?
>
> Yeah, I don't think we need to go too mad here. Drivers shouldn't emit
> their *own* -EINVAL unless appropriate, but if it comes back from some
> external API then that implies something's gone unexpectedly wrong
> anyway - maybe it's a transient condition and a subsequent different
> attach might actually work out OK? We can't really say in general.
OK. Then there's even no need to convert EINVAL to ENODEV.
> Besides, if the driver sees an error which implies it's done something
> wrong itself, it probably shouldn't be trusted to try to reason about it
> further. The caller can handle any error as long as we set their
> expectations correctly.
Yea. As Jason remarked, a wrongly returned EINVAL would make things
a bit inefficient: VFIO/IOMMUFD would keep trying attach_dev() with
its existing domain list and a new domain but fail all of them.
I will change things in v2 back to this 2-patch version, and maybe
limit a bit further the changes in the first NODEV patch.
Thanks!
Nic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 5/5] iommu: Use EINVAL for incompatible device/domain in ->attach_dev
2022-09-13 8:24 [PATCH 0/5] iommu: Define EINVAL as device/domain incompatibility Nicolin Chen
` (3 preceding siblings ...)
2022-09-13 8:24 ` [PATCH 4/5] iommu: Regulate errno in ->attach_dev callback functions Nicolin Chen
@ 2022-09-13 8:24 ` Nicolin Chen
4 siblings, 0 replies; 15+ messages in thread
From: Nicolin Chen @ 2022-09-13 8:24 UTC (permalink / raw)
To: joro, suravee.suthikulpanit, will, robin.murphy, robdclark,
dwmw2, baolu.lu, agross, bjorn.andersson, konrad.dybcio,
matthias.bgg, heiko, orsonzhai, baolin.wang, zhang.lyra,
thierry.reding, jean-philippe, jgg, sricharan
Cc: linux-kernel, linux-arm-msm, yangyingliang, jon, iommu,
shameerali.kolothum.thodi, jonathanh, linux-rockchip,
christophe.jaillet, linux-arm-kernel, thunder.leizhen,
linux-tegra, linux-mediatek, tglx, virtualization, yong.wu
Following the new rules in include/linux/iommu.h kdocs, update all drivers
->attach_dev callback functions to return EINVAL in the failure paths that
are related to domain incompatibility.
Also drop adjacent error prints to prevent a kernel log spam, since EINVAL
exclusively means an incompatibility error.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 11 +----------
drivers/iommu/arm/arm-smmu/arm-smmu.c | 3 ---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 7 +------
drivers/iommu/intel/iommu.c | 10 +++-------
drivers/iommu/ipmmu-vmsa.c | 2 --
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/sprd-iommu.c | 4 +---
drivers/iommu/tegra-gart.c | 2 +-
drivers/iommu/virtio-iommu.c | 4 ++--
9 files changed, 10 insertions(+), 35 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 0186dfdf31fe..8b5a2e8de7e2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2429,23 +2429,14 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
goto out_unlock;
}
} else if (smmu_domain->smmu != smmu) {
- dev_err(dev,
- "cannot attach to SMMU %s (upstream of %s)\n",
- dev_name(smmu_domain->smmu->dev),
- dev_name(smmu->dev));
- ret = -ENXIO;
+ ret = -EINVAL;
goto out_unlock;
} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 &&
master->ssid_bits != smmu_domain->s1_cfg.s1cdmax) {
- dev_err(dev,
- "cannot attach to incompatible domain (%u SSID bits != %u)\n",
- smmu_domain->s1_cfg.s1cdmax, master->ssid_bits);
ret = -EINVAL;
goto out_unlock;
} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 &&
smmu_domain->stall_enabled != master->stall_enabled) {
- dev_err(dev, "cannot attach to stall-%s domain\n",
- smmu_domain->stall_enabled ? "enabled" : "disabled");
ret = -EINVAL;
goto out_unlock;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 771dd161545c..63a488f2f16c 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1167,9 +1167,6 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
* different SMMUs.
*/
if (smmu_domain->smmu != smmu) {
- dev_err(dev,
- "cannot attach to SMMU %s whilst already attached to domain on SMMU %s\n",
- dev_name(smmu_domain->smmu->dev), dev_name(smmu->dev));
ret = -EINVAL;
goto rpm_put;
}
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index 49d40c80afd3..542fa8c4b6cb 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -381,13 +381,8 @@ static int qcom_iommu_attach_dev(struct iommu_domain *domain, struct device *dev
* Sanity check the domain. We don't support domains across
* different IOMMUs.
*/
- if (qcom_domain->iommu != qcom_iommu) {
- dev_err(dev, "cannot attach to IOMMU %s while already "
- "attached to domain on IOMMU %s\n",
- dev_name(qcom_domain->iommu->dev),
- dev_name(qcom_iommu->dev));
+ if (qcom_domain->iommu != qcom_iommu)
return -EINVAL;
- }
return 0;
}
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 1f2cd43cf9bc..51ef42b1bd4e 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4158,19 +4158,15 @@ static int prepare_domain_attach_device(struct iommu_domain *domain,
return -ENODEV;
if (dmar_domain->force_snooping && !ecap_sc_support(iommu->ecap))
- return -EOPNOTSUPP;
+ return -EINVAL;
/* check if this iommu agaw is sufficient for max mapped address */
addr_width = agaw_to_width(iommu->agaw);
if (addr_width > cap_mgaw(iommu->cap))
addr_width = cap_mgaw(iommu->cap);
- if (dmar_domain->max_addr > (1LL << addr_width)) {
- dev_err(dev, "%s: iommu width (%d) is not "
- "sufficient for the mapped address (%llx)\n",
- __func__, addr_width, dmar_domain->max_addr);
- return -EFAULT;
- }
+ if (dmar_domain->max_addr > (1LL << addr_width))
+ return -EINVAL;
dmar_domain->gaw = addr_width;
/*
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index cb14abcfa43a..cb8ce8af0bff 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -628,8 +628,6 @@ static int ipmmu_attach_device(struct iommu_domain *io_domain,
* Something is wrong, we can't attach two devices using
* different IOMMUs to the same domain.
*/
- dev_err(dev, "Can't attach IPMMU %s to domain on IPMMU %s\n",
- dev_name(mmu->dev), dev_name(domain->mmu->dev));
ret = -EINVAL;
} else
dev_info(dev, "Reusing IPMMU context %u\n", domain->context_id);
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 447e40d55918..be12f49140c7 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1472,7 +1472,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
/* only a single client device can be attached to a domain */
if (omap_domain->dev) {
dev_err(dev, "iommu domain is already attached\n");
- ret = -EBUSY;
+ ret = -EINVAL;
goto out;
}
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
index 511959c8a14d..945576039c9e 100644
--- a/drivers/iommu/sprd-iommu.c
+++ b/drivers/iommu/sprd-iommu.c
@@ -237,10 +237,8 @@ static int sprd_iommu_attach_device(struct iommu_domain *domain,
struct sprd_iommu_domain *dom = to_sprd_domain(domain);
size_t pgt_size = sprd_iommu_pgt_size(domain);
- if (dom->sdev) {
- pr_err("There's already a device attached to this domain.\n");
+ if (dom->sdev)
return -EINVAL;
- }
dom->pgt_va = dma_alloc_coherent(sdev->dev, pgt_size, &dom->pgt_pa, GFP_KERNEL);
if (!dom->pgt_va)
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index e5ca3cf1a949..ed53279d1106 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -112,7 +112,7 @@ static int gart_iommu_attach_dev(struct iommu_domain *domain,
spin_lock(&gart->dom_lock);
if (gart->active_domain && gart->active_domain != domain) {
- ret = -EBUSY;
+ ret = -EINVAL;
} else if (dev_iommu_priv_get(dev) != domain) {
dev_iommu_priv_set(dev, domain);
gart->active_domain = domain;
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 874c01634d2b..a252cd1daf70 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -733,8 +733,8 @@ static int viommu_attach_dev(struct iommu_domain *domain, struct device *dev)
*/
ret = viommu_domain_finalise(vdev, domain);
} else if (vdomain->viommu != vdev->viommu) {
- dev_err(dev, "cannot attach to foreign vIOMMU\n");
- ret = -EXDEV;
+ /* cannot attach to foreign vIOMMU */
+ ret = -EINVAL;
}
mutex_unlock(&vdomain->mutex);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 15+ messages in thread