linux-kernel - Re: [PATCH v9 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260127191938.GR1134360@nvidia.com>
Date: Tue, 27 Jan 2026 15:19:38 -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: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