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

[Nicolin Chen <nicolinc@nvidia.com>]

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.

Nicolin