Re: [PATCH 3/5] locking/rwsem: add down_read[_killable]_nosteal()

From: Lorenzo Stoakes (ARM)

Date: Thu Nov 05 2026 - 05:31:31 EST


On Thu, Nov 05, 2026 at 11:25:25AM +0100, David Hildenbrand (Arm) wrote:
> On 11/3/26 13:24, Lorenzo Stoakes (ARM) wrote:
> > On Tue, Nov 03, 2026 at 12:51:59PM +0100, Peter Zijlstra wrote:
> >> On Tue, Nov 03, 2026 at 08:27:44AM +0000, Lorenzo Stoakes (ARM) wrote:
> >>> Since commit 1a728dff855a ("locking/rwsem: Enable reader optimistic lock
> >>> stealing") a sleeping, queued writer whose handoff timeout hasn't expired
> >>> can have its lock stolen by a read lock issued before a woken queued writer
> >>> was able to acquire a lock.
> >>>
> >>> To avoid write lock starvation, this is only permitted if no other read
> >>> locks are held.
> >>>
> >>> However, this behaviour defeats the purpose of a reader periodically
> >>> dropping the lock to allow writers in, as doing so only works if the write
> >>> lock is acquired first, another read lock is held, or a queued writer's
> >>> handoff timeout has expired.
> >>>
> >>> Provide a means of indicating this intent via down_read_nosteal() and
> >>> down_read_killable_nosteal().
> >>>
> >>> Implement it by exposing a steal parameter to rwsem_down_read_slowpath(),
> >>> update the starvation logic to modify this parameter and modify the steal
> >>> branch to check it first.
> >>>
> >>> Also drop the duplicated RWSEM_WRITER_LOCKED check and remove the
> >>> goto as the steal condition makes this redundant.
> >>>
> >>> Exposing this function is safe as it only makes the lock more pessimistic,
> >>> so does not impact lock contention.
> >>
> >> Not generally a fan of this -- can't we tweak the steal thing to never
> >> steal if there are pending writers?
> >
> > Oh, well, I had assumed I couldn't fiddle with that behaviour across
> > rwsem's in general, so if I can yeah that's preferable!
> >
> > I could send that change separately then and drop it out of this series.
>
> Just so I understand correctly, this patch here would be gone entirely?
>
> But #4 depends on it, so now I'm confused :)

#4 would go too :P see, making your life easier ;)

I'll try sending the rwsem separately, then respin this one.


--
Cheers, Lorenzo