Re: [PATCH RESEND 1/3] locking: add rwsem_is_write_locked(), update non-lockdep asserts
From: Lorenzo Stoakes
Date: Fri Jan 16 2026 - 11:56:46 EST
On Fri, Jan 16, 2026 at 05:41:39PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-01-16 16:21:29 [+0000], Lorenzo Stoakes wrote:
> > On Fri, Jan 16, 2026 at 04:57:43PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2026-01-16 15:50:24 [+0000], Lorenzo Stoakes wrote:
> > > > No, but we need to be able to assert that one of two locks are held and we
> > > > don't want the failure of one being held to cause an assert when the other
> > > > isn't.
> > >
> > > But why don't you use the lockdep based check? That assert only ensures
> >
> > Not sure what you mean, the checks I'm adding don't exist yet.
>
> The checks you add are not lockdep.
I understand that thanks (?)
I'm not sure responding point by point is productive here, so let me
summarise:
We often run code locally without lockdep, testing isn't always ideal
across mm and these asserts are gated by CONFIG_DEBUG_VM anyway so yes I
want a non-lockdep version also.
Note that existing mm lock asserts already work this way, so that's
consistent (though mmap asserts are also at runtime...)
I can't just use existing asserts because I need to test that EITHER one
lock OR the other is held. If there's a way to do that with lockdep in a
way other than what I have suggested, I am more than happy to hear it?
If not I'll respin this with both a lockdep + not-lockdep version.
What you're suggesting, just using the existing lockdep asserts, won't work
unless I'm missing something, because of this _either_ lock requirement.
But if there is an existing solution that you can point me at I'd be more
than happy to use it.
Thanks, Lorenzo