[PATCH v9 02/12] iommu/arm-smmu-v3: Add a helper to drain cmd queues
Nicolin Chen
nicolinc at nvidia.com
Tue Aug 25 11:20:54 PDT 2026
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
More information about the linux-arm-kernel
mailing list