[PATCH v9 02/12] iommu/arm-smmu-v3: Add a helper to drain cmd queues

Pranjal Shrivastava praan at google.com
Tue Aug 25 11:57:18 PDT 2026


On Tue, Aug 25, 2026 at 11:20:54AM -0700, Nicolin Chen wrote:
> On Tue, Aug 25, 2026 at 05:37:42PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Aug 25, 2026 at 01:36:11PM -0300, Jason Gunthorpe wrote:
> > > > [ ... 36 lines skipped ... ]
> > > > +		if (queue_empty(llq))
> > > 
> > >  [Severity: High]
> > >  Does polling for an empty CMDQ actually guarantee that commands have completed?
> > > 
> > >  queue_empty() relies on the SMMU consumer register equaling the producer
> > >  pointer. However, for CMD_SYNC, the SMMU advances the consumer register
> > >  immediately upon consumption, not upon completion. Suspending the SMMU while
> > >  commands like ATC_INV are still in-flight could abort them, leaving stale
> > >  translations in the device ATC and causing submitters to time out.
> > > 
> > > This seems broadly wrong, but it doesn't seem explained very well,
> > > maybe put a comment above the function something like
> > > 
> > >  The caller must have ensured that no concurrent command submission
> > >  can happen. Thus the entry at the PROD must be a CMD_SYNC due to how
> > >  all submitters generate commands. Waiting for PROD==CONS guarentees
> > >  completion of the sync and all prior work and thus idle HW.
> > > 
> > > I don't think the other substantive remarks are valid.
> > > 
> > > The Werror thing is right, every patch should compile alone without
> > > warnings. Sometimes people add __maybe_unused to accomplish this..
> > >
> > 
> > Ack. I plan to add __maybe_unused here.
> 
> Maybe it's time to use the shared helper in both of our series?
> 
> I plan to send PRI-v3 on rc1 (likely next week) with this:
> https://github.com/nicolinc/iommufd/commit/d10325ff40fd45c476bc98d484d8dd2cdc7fdf95
> 
> I think this series can take it (and its parent Q_POS as well),
> as we discussed in the other mail.
> 

Ack. I agree, I can pick up Q_POS & the common drain helper here.

> Nicolin

Thanks,
Praan



More information about the linux-arm-kernel mailing list