Re: [PATCH v6 07/10] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops

[Pranjal Shrivastava <praan@google.com>]

On Fri, Apr 24, 2026 at 12:13:25PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2026 at 01:40:53PM +0000, Pranjal Shrivastava wrote:
> 
> > > > +/*
> > > > + * This should always return true if devlinks are setup correctly
> > > > + * and the client using the SMMU is active.
> > > > + */
> > > > +__maybe_unused bool arm_smmu_rpm_get_if_active(struct arm_smmu_device *smmu)
> > > > +{
> > > > +       if (!arm_smmu_is_active(smmu))
> > > > +               return false;
> > > 
> > > I'm wondering if this check is redundant. What would happen if we removed it?
> > > 
> > 
> > You're right that pm_runtime_get_if_active() shall suffice. However, I
> > added the arm_smmu_is_active() check as a lockless fast path for unmaps
> > 
> > Consider a scneario where there're high-frequency unmaps (unmap-storm)
> > while the SMMU is suspended. Without this check, every thread would 
> > contend for the dev->power.lock spinlock inside the RPM core 
> > (pm_runtime_get_if_active) just to discover the device is not active.
> > 
> > This check allows CPUs to elide the command immediately without
> > contending for the dev->power.lock spinlock inside the RPM core
> > (get_if_active call) and avoids unnecessary cacheline bouncing when the
> > SMMU is suspended.
> 
> But these sorts of pre checks are almost always racy, I think you need a
> comment or lockdep statement explaining how the locking works. 

Ack. It is a benign race in this case and the check serves as a
performance heuristic to avoid dev->power.lock contention during unmap 
storms while the SMMU is suspended.

The race is safe because the check is layered:
if a thread incorrectly passes this pre-check while the SMMU is 
suspending, it will either be caught by the subsequent call to
pm_runtime_get_if_active() or by the final, Q_STOP check in the
arm_smmu_cmdq_issue_cmdlist() at the point of commitment.

I'll add a comment explaining this approach to clarify the intent.

Thanks,
Praan