[PATCH v3 05/11] iommu: Change group->devices to RCU-protected list

[Nicolin Chen]

On Fri, Apr 24, 2026 at 07:58:20PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 12:12:40PM -0700, Nicolin Chen wrote:
> > On Fri, Apr 24, 2026 at 10:11:48AM -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 23, 2026 at 08:08:59PM -0700, Nicolin Chen wrote:
> > > > On Fri, Apr 24, 2026 at 10:53:49AM +0800, Baolu Lu wrote:
> > > > > On 4/17/26 07:28, Nicolin Chen wrote:
> > > > > 	    mutex_unlock(&group->mutex);
> > > > >             /*
> > > > >              * FIXME: Mis-locked because the ops->probe_finalize() call-back
> > > > >              * of some IOMMU drivers calls arm_iommu_attach_device() which
> > > > >              * in-turn might call back into IOMMU core code, where it tries
> > > > >              * to take group->mutex, resulting in a deadlock.
> > > > >              */
> > > > >              for_each_group_device(group, gdev)
> > > > >                         iommu_group_do_probe_finalize(gdev->dev);
> > > > >         }
> > > > > 
> > > > >         return 0;
> > > > > }
> > > > > 
> > > > > Will the change above trigger a lockdep splat due to this "mis-locked"
> > > > > case?"
> > > > 
> > > > Oh, I missed this one. That's a good finding!
> > > > 
> > > > Perhaps we can just change it to list_for_each_entry_rcu holding
> > > > rcu_read_lock() and drop the FIXME.
> > > 
> > > You can't hold rcu across that function IIRC
> > 
> > Oh right. I didn't think too carefully...
> > 
> > I tend to keep it as-is. So, maybe just list_for_each_entry?
> 
> Does your series make this existing race materially worse?

I think it would be a status quo.

The only possible place is __iommu_group_remove_device() that this
series touched by changing the kfree(gdev) within the mutex to the
kfree_rcu(gdev, rcu) outside the mutex, which actually added small
delay. Though that doesn't fix a potential race, it shouldn't make
things worse.

Nicolin