[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260127182348.GP1134360@nvidia.com>
Date: Tue, 27 Jan 2026 14:23:48 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: Pranjal Shrivastava <praan@...gle.com>, will@...nel.org,
jean-philippe@...aro.org, robin.murphy@....com, joro@...tes.org,
balbirs@...dia.com, miko.lenczewski@....com, peterz@...radead.org,
kevin.tian@...el.com, linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based
arm_smmu_domain_inv_range()
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.
Jason
Powered by blists - more mailing lists