linux-kernel - Re: [PATCH v4 2/2] iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiency

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: <20251130145236.0000009d@linux.microsoft.com>
Date: Sun, 30 Nov 2025 14:52:36 -0800
From: Jacob Pan <jacob.pan@...ux.microsoft.com>
To: Will Deacon <will@...nel.org>
Cc: linux-kernel@...r.kernel.org, "iommu@...ts.linux.dev"
 <iommu@...ts.linux.dev>, Joerg Roedel <joro@...tes.org>, Mostafa Saleh
 <smostafa@...gle.com>, Jason Gunthorpe <jgg@...dia.com>, Robin Murphy
 <robin.murphy@....com>, Nicolin Chen <nicolinc@...dia.com>, Zhang Yu
 <zhangyu1@...ux.microsoft.com>, Jean Philippe-Brucker
 <jean-philippe@...aro.org>, Alexander Grest <Alexander.Grest@...rosoft.com>
Subject: Re: [PATCH v4 2/2] iommu/arm-smmu-v3: Improve CMDQ lock fairness
 and efficiency

Hi Will,

On Tue, 25 Nov 2025 17:18:57 +0000
Will Deacon <will@...nel.org> wrote:

> On Fri, Nov 14, 2025 at 09:17:18AM -0800, Jacob Pan wrote:
> > @@ -521,9 +527,14 @@ static bool
> > arm_smmu_cmdq_shared_tryunlock(struct arm_smmu_cmdq *cmdq)
> > __ret;
> > 	\ }) 
> > +/*
> > + * Only clear the sign bit when releasing the exclusive lock this
> > will
> > + * allow any shared_lock() waiters to proceed without the
> > possibility
> > + * of entering the exclusive lock in a tight loop.
> > + */
> >  #define arm_smmu_cmdq_exclusive_unlock_irqrestore(cmdq,
> > flags)		\ ({
> > 				\
> > -	atomic_set_release(&cmdq->lock, 0);
> > 	\
> > +	atomic_fetch_and_release(~INT_MIN, &cmdq->lock);
> > 	\  
> 
> nit: you can use atomic_fetch_andnot_release(INT_MIN)
> 
Good point, will do.

> That aside, doesn't this introduce a new fairness issue in that a
> steady stream of shared lockers will starve somebody trying to take
> the lock in exclusive state?
> 
I don't think this change will starve exclusive lockers in the
current code flow since new shared locker must acquire exclusive locker
first while polling for available queue spaces.