Move the list_add() call to the end of msm_iommu_probe() instead of
adding cleanup paths, which avoids the dangling list entry problem
entirely (suggested by Mukesh Ojha).

This approach simplifies the code by ensuring the iommu device is
never added to the global list until after all potential failure
points have passed.

Changes in v3:
- Move list_add() to the end instead of adding cleanup labels
  (suggested by Mukesh Ojha)

Changes in v2:
- Resend the former patch 4/4 independently; patches 1-3 from v1
  are dropped.
- Explain the dangling list entry and stale sysfs device consequences.
- Add Fixes and stable tags.
- No code changes.

Fixes: 42df43b36163 ("iommu/msm: Make use of iommu_device_register interface")
Cc: stable@vger.kernel.org
Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
---
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 0ad5ff431..9da650a82 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -778,8 +778,6 @@ static int msm_iommu_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	list_add(&iommu->dev_node, &qcom_iommu_devices);
-
 	ret = iommu_device_sysfs_add(&iommu->iommu, iommu->dev, NULL,
 				     "msm-smmu.%pa", &ioaddr);
 	if (ret) {
@@ -790,9 +788,12 @@ static int msm_iommu_probe(struct platform_device *pdev)
 	ret = iommu_device_register(&iommu->iommu, &msm_iommu_ops, &pdev->dev);
 	if (ret) {
 		pr_err("Could not register msm-smmu at %pa\n", &ioaddr);
+		iommu_device_sysfs_remove(&iommu->iommu);
 		return ret;
 	}
 
+	list_add(&iommu->dev_node, &qcom_iommu_devices);
+
 	pr_info("device mapped at %p, irq %d with %d ctx banks\n",
 		iommu->base, iommu->irq, iommu->ncb);
 
-- 
2.34.1

On Thu, 16 Jul 2026 16:53:12 +0800, Weimin Xiong wrote:
> Move the list_add() call to the end of msm_iommu_probe() instead of
> adding cleanup paths, which avoids the dangling list entry problem
> entirely (suggested by Mukesh Ojha).
> 
> This approach simplifies the code by ensuring the iommu device is
> never added to the global list until after all potential failure
> points have passed.
> 
> [...]

Applied to iommu (qualcomm/msm), thanks!

[1/1] iommu/msm: Fix dangling list entry on probe failure
      https://git.kernel.org/iommu/c/6bea37b176b8

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

On Wed, Jul 22, 2026 at 10:39:34PM +0100, Will Deacon wrote:
> On Thu, 16 Jul 2026 16:53:12 +0800, Weimin Xiong wrote:
> > Move the list_add() call to the end of msm_iommu_probe() instead of
> > adding cleanup paths, which avoids the dangling list entry problem
> > entirely (suggested by Mukesh Ojha).
> > 
> > This approach simplifies the code by ensuring the iommu device is
> > never added to the global list until after all potential failure
> > points have passed.
> > 
> > [...]
> 
> Applied to iommu (qualcomm/msm), thanks!
> 
> [1/1] iommu/msm: Fix dangling list entry on probe failure
>       https://git.kernel.org/iommu/c/6bea37b176b8

Will,

By mistake you have taken the wrong one; it should be v2, not v3 that
should be picked. Sorry for the confusion.

-- 
-Mukesh Ojha

On Thu, Jul 23, 2026 at 10:19:44PM +0530, Mukesh Ojha wrote:
> On Wed, Jul 22, 2026 at 10:39:34PM +0100, Will Deacon wrote:
> > On Thu, 16 Jul 2026 16:53:12 +0800, Weimin Xiong wrote:
> > > Move the list_add() call to the end of msm_iommu_probe() instead of
> > > adding cleanup paths, which avoids the dangling list entry problem
> > > entirely (suggested by Mukesh Ojha).
> > > 
> > > This approach simplifies the code by ensuring the iommu device is
> > > never added to the global list until after all potential failure
> > > points have passed.
> > > 
> > > [...]
> > 
> > Applied to iommu (qualcomm/msm), thanks!
> > 
> > [1/1] iommu/msm: Fix dangling list entry on probe failure
> >       https://git.kernel.org/iommu/c/6bea37b176b8
> 
> Will,
> 
> By mistake you have taken the wrong one; it should be v2, not v3 that
> should be picked. Sorry for the confusion.

Damn, so close!

I had already realised I wanted the v2, so I'd flagged that to be applied
and marked the v3 as "read". I then carefully passed the message-id of
v2 to my wrapper script around b4...

... which invokes b4 with the '-c' option, causing it to check for newer
revisions. D'oh!

I think I'll just revert the v3 and try again with the v2.

Will

On Fri, Jul 24, 2026 at 01:33:37PM +0100, Will Deacon wrote:
> On Thu, Jul 23, 2026 at 10:19:44PM +0530, Mukesh Ojha wrote:
> > On Wed, Jul 22, 2026 at 10:39:34PM +0100, Will Deacon wrote:
> > > On Thu, 16 Jul 2026 16:53:12 +0800, Weimin Xiong wrote:
> > > > Move the list_add() call to the end of msm_iommu_probe() instead of
> > > > adding cleanup paths, which avoids the dangling list entry problem
> > > > entirely (suggested by Mukesh Ojha).
> > > > 
> > > > This approach simplifies the code by ensuring the iommu device is
> > > > never added to the global list until after all potential failure
> > > > points have passed.
> > > > 
> > > > [...]
> > > 
> > > Applied to iommu (qualcomm/msm), thanks!
> > > 
> > > [1/1] iommu/msm: Fix dangling list entry on probe failure
> > >       https://git.kernel.org/iommu/c/6bea37b176b8
> > 
> > Will,
> > 
> > By mistake you have taken the wrong one; it should be v2, not v3 that
> > should be picked. Sorry for the confusion.
> 
> Damn, so close!
> 
> I had already realised I wanted the v2, so I'd flagged that to be applied
> and marked the v3 as "read". I then carefully passed the message-id of
> v2 to my wrapper script around b4...
> 
> ... which invokes b4 with the '-c' option, causing it to check for newer
> revisions. D'oh!

Urgh, v3 is a reply to v2 so even without that option is still gets the
wrong patch. I'll just apply it manually.

> I think I'll just revert the v3 and try again with the v2.

On second thoughts, I'll replace the patch to avoid confusion with stable.

Will

On 7/16/26 10:53 AM, Weimin Xiong wrote:
> Move the list_add() call to the end of msm_iommu_probe() instead of
> adding cleanup paths, which avoids the dangling list entry problem
> entirely (suggested by Mukesh Ojha).
> 
> This approach simplifies the code by ensuring the iommu device is
> never added to the global list until after all potential failure
> points have passed.
> 
> Changes in v3:
> - Move list_add() to the end instead of adding cleanup labels
>   (suggested by Mukesh Ojha)

I think this approach introduces a race condition, because e.g.
iommu_ops->of_xlate() depends on the item being present in this list

Konrad

On 16/07/2026 10:42 am, Konrad Dybcio wrote:
> On 7/16/26 10:53 AM, Weimin Xiong wrote:
>> Move the list_add() call to the end of msm_iommu_probe() instead of
>> adding cleanup paths, which avoids the dangling list entry problem
>> entirely (suggested by Mukesh Ojha).
>>
>> This approach simplifies the code by ensuring the iommu device is
>> never added to the global list until after all potential failure
>> points have passed.
>>
>> Changes in v3:
>> - Move list_add() to the end instead of adding cleanup labels
>>    (suggested by Mukesh Ojha)
> 
> I think this approach introduces a race condition, because e.g.
> iommu_ops->of_xlate() depends on the item being present in this list

Yes, the IOMMU instance must be ready to be fully functional *before* 
calling iommu_device_register(), since that can start probing and 
attaching client devices before it returns.

Thanks,
Robin.

On Thu, Jul 16, 2026 at 01:05:57PM +0100, Robin Murphy wrote:
> On 16/07/2026 10:42 am, Konrad Dybcio wrote:
> > On 7/16/26 10:53 AM, Weimin Xiong wrote:
> > > Move the list_add() call to the end of msm_iommu_probe() instead of
> > > adding cleanup paths, which avoids the dangling list entry problem
> > > entirely (suggested by Mukesh Ojha).
> > > 
> > > This approach simplifies the code by ensuring the iommu device is
> > > never added to the global list until after all potential failure
> > > points have passed.
> > > 
> > > Changes in v3:
> > > - Move list_add() to the end instead of adding cleanup labels
> > >    (suggested by Mukesh Ojha)
> > 
> > I think this approach introduces a race condition, because e.g.
> > iommu_ops->of_xlate() depends on the item being present in this list
> 
> Yes, the IOMMU instance must be ready to be fully functional *before*
> calling iommu_device_register(), since that can start probing and attaching
> client devices before it returns.

Right..I overlooked it.

v2 is fine ..


@Weimin,  JFYI, Always send patch revision as a new thread not as a reply of
previous version.

-- 
-Mukesh Ojha