Re: [PATCH v9 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range()

Jason Gunthorpe
2026-01-27T19:19:42Z

On Tue, Jan 27, 2026 at 10:37:44AM -0800, Nicolin Chen wrote:
> On Tue, Jan 27, 2026 at 02:23:48PM -0400, Jason Gunthorpe wrote:
> > On Tue, Jan 27, 2026 at 10:07:09AM -0800, Nicolin Chen wrote:
> > > > My understanding has been that this invalidation can run from an IRQ
> > > > context - we permit the use of the DMA API from an interrupt handler?
> > > >
> > > > I though that for rwsem the read side does not require the _irqsave,
> > > > even if it is in an irq context, unless the write side runs from an
> > > > IRQ.
> > >
> > > Hmm, is "rwsem" a typo? Because it's rwlock_t, which is spinlock :-/
> >
> > Yeah, sorry
> >
> > > > Here the write side always runs from a process context.
> > > >
> > > > So the write side will block the IRQ which ensures we don't spin
> > > > during read in an IRQ.
> > >
> > > And, does write_lock_irqsave() disable global IRQ or local IRQ only?
> > >
> > > Documentation/locking/locktypes.rst mentions "local_irq_disable()"..
> >
> > It will only disable the local IRQ, since it is a spin type lock an IRQ on
> > another CPU can spin until it is unlocked.
> >
> > The main issue is if this CPU takes an IRQ while the write side is
> > locked and spins, then it will never unlock.
>
> Yea, that sounds unsafe. I'll send a v11 with read_lock_irqsave().

I'm explaining why it is safe now, the write side takes the irqsave so
the above can't happen.

There is no case where the read side needs to block IRQ because if the
read side succeeds, an IRQ happens and tries to take another read
side, it will succeed not spin.

But it is a very very small optimization so let's just go ahead with
the thing that is obviously safe.

Jason