Make sure to drop the reference taken to the iommu platform device when looking up its driver data during probe_device().
Note that commit 9826e393e4a8 ("iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find") fixed the leak in an error path, but the reference is still leaking on success.
Fixes: 891846516317 ("memory: Add NVIDIA Tegra memory controller support") Cc: stable@vger.kernel.org # 3.19: 9826e393e4a8 Cc: Thierry Reding treding@nvidia.com Cc: Miaoqian Lin linmq006@gmail.com Acked-by: Robin Murphy robin.murphy@arm.com Signed-off-by: Johan Hovold johan@kernel.org --- drivers/iommu/tegra-smmu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c index 36cdd5fbab07..f6f26a072820 100644 --- a/drivers/iommu/tegra-smmu.c +++ b/drivers/iommu/tegra-smmu.c @@ -830,10 +830,9 @@ static struct tegra_smmu *tegra_smmu_find(struct device_node *np) return NULL;
mc = platform_get_drvdata(pdev); - if (!mc) { - put_device(&pdev->dev); + put_device(&pdev->dev); + if (!mc) return NULL; - }
return mc->smmu; }
On Tue, Oct 07, 2025 at 11:43:27AM +0200, Johan Hovold wrote:
Make sure to drop the reference taken to the iommu platform device when looking up its driver data during probe_device().
Note that commit 9826e393e4a8 ("iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find") fixed the leak in an error path, but the reference is still leaking on success.
Fixes: 891846516317 ("memory: Add NVIDIA Tegra memory controller support") Cc: stable@vger.kernel.org # 3.19: 9826e393e4a8 Cc: Thierry Reding treding@nvidia.com Cc: Miaoqian Lin linmq006@gmail.com Acked-by: Robin Murphy robin.murphy@arm.com Signed-off-by: Johan Hovold johan@kernel.org
drivers/iommu/tegra-smmu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c index 36cdd5fbab07..f6f26a072820 100644 --- a/drivers/iommu/tegra-smmu.c +++ b/drivers/iommu/tegra-smmu.c @@ -830,10 +830,9 @@ static struct tegra_smmu *tegra_smmu_find(struct device_node *np) return NULL; mc = platform_get_drvdata(pdev);
- if (!mc) {
put_device(&pdev->dev);
- put_device(&pdev->dev);
- if (!mc) return NULL;
- }
return mc->smmu;
pdev->dev is what's backing mc, so if we use put_device() here, then the MC could go away at any time, right?
So the goal here was to make sure that the MC stays around during the entire lifetime of the IOMMU attachment. We don't currently release that reference, ever, so there is a leak, but wouldn't it be more appropriate to release it in a .release_device implementation?
Thierry
On Thu, Oct 09, 2025 at 09:56:18AM +0200, Thierry Reding wrote:
On Tue, Oct 07, 2025 at 11:43:27AM +0200, Johan Hovold wrote:
@@ -830,10 +830,9 @@ static struct tegra_smmu *tegra_smmu_find(struct device_node *np) return NULL; mc = platform_get_drvdata(pdev);
- if (!mc) {
put_device(&pdev->dev);
- put_device(&pdev->dev);
- if (!mc) return NULL;
- }
return mc->smmu;
pdev->dev is what's backing mc, so if we use put_device() here, then the MC could go away at any time, right?
Holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
But from what I can tell, you don't need to worry about that anyway since it's the memory controller driver that registers the iommu (and the driver can't be unbound).
Johan
On Thu, Oct 09, 2025 at 10:27:55AM +0200, Johan Hovold wrote:
On Thu, Oct 09, 2025 at 09:56:18AM +0200, Thierry Reding wrote:
On Tue, Oct 07, 2025 at 11:43:27AM +0200, Johan Hovold wrote:
@@ -830,10 +830,9 @@ static struct tegra_smmu *tegra_smmu_find(struct device_node *np) return NULL; mc = platform_get_drvdata(pdev);
- if (!mc) {
put_device(&pdev->dev);
- put_device(&pdev->dev);
- if (!mc) return NULL;
- }
return mc->smmu;
pdev->dev is what's backing mc, so if we use put_device() here, then the MC could go away at any time, right?
Holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.
But from what I can tell, you don't need to worry about that anyway since it's the memory controller driver that registers the iommu (and the driver can't be unbound).
That's true. It'd be nice to at least conceptually do the right thing here, but not sure it's worth it. As you said, driver data going away would need special handling and it's not even clear what that would mean in terms of the clients...
Acked-by: Thierry Reding treding@nvidia.com
linux-stable-mirror@lists.linaro.org
-
Johan Hovold -
Thierry Reding