Re: [PATCH v6 06/10] iommu/arm-smmu-v3: Add CMDQ_PROD_STOP_FLAG to gate CMDQ submissions

[Pranjal Shrivastava <praan@google.com>]

On Tue, Apr 21, 2026 at 09:31:33PM -0700, Daniel Mentz wrote:
> On Tue, Apr 14, 2026 at 12:47 PM Pranjal Shrivastava <praan@google.com> wrote:
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -209,7 +209,8 @@ static int queue_sync_prod_in(struct arm_smmu_queue *q)
> >  static u32 queue_inc_prod_n(struct arm_smmu_ll_queue *q, int n)
> >  {
> >         u32 prod = (Q_WRP(q, q->prod) | Q_IDX(q, q->prod)) + n;
> > -       return Q_OVF(q->prod) | Q_WRP(q, prod) | Q_IDX(q, prod);
> > +
> > +       return Q_OVF(q->prod) | Q_STOP(q->prod) | Q_WRP(q, prod) | Q_IDX(q, prod);
> 
> Is there a situation where we need to increment prod and retain the
> STOP flag? What happens if we leave this particular line as is?
> 

The CMDQ_PROD_STOP_FLAG must be preserved in queue_inc_prod_n() to
prevent it from being accidentally cleared during after being set.
This can happen in the following cases:

1. Point of Commitment Races: In arm_smmu_cmdq_issue_cmdlist(), a thread
   could pass the initial Q_STOP check and successfully cmpxchg (commit)
   its indices. If the suspend handler then sets the STOP_FLAG before the
   thread reaches the if (sync) block, the thread will subsequently call
   queue_inc_prod_n() to calculate indices for the sync command. If the
   flag is not sticky here, this call would overwrite the global state
   and inadvertently clear the STOP_FLAG, re-opening the queue for new
   submissions while the SMMU is trying to suspend.

2. GERROR: If a Gerror occurs during the suspend, the handler 
(arm_smmu_cmdq_skip_err) may increment the producer index to bypass a
faulty command. Since this handler could be asynchronous, we must ensure
that the STOP_FLAG is respoected. Preserving the flag ensures that we
don't accidentally clear the flag.


> >  }

Thanks,
Praan