linux-kernel - Re: [PATCH v4 04/10] mm/vma: add+use vma lockdep acquire/release defines

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: <CAJuCfpG+Ci2JSskDuE09jzdReXP-06Bu7XfeHTySBwQXb_dYtQ@mail.gmail.com>
Date: Thu, 29 Jan 2026 13:30:32 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Andrew Morton <akpm@...ux-foundation.org>, 
	David Hildenbrand <david@...nel.org>, "Liam R . Howlett" <Liam.Howlett@...cle.com>, 
	Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, Michal Hocko <mhocko@...e.com>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Jann Horn <jannh@...gle.com>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, 
	Boqun Feng <boqun.feng@...il.com>, Waiman Long <longman@...hat.com>, 
	Clark Williams <clrkwllms@...nel.org>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v4 04/10] mm/vma: add+use vma lockdep acquire/release defines

On Wed, Jan 28, 2026 at 3:48 AM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> On Wed, Jan 28, 2026 at 12:37:49PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2026-01-23 20:12:14 [+0000], Lorenzo Stoakes wrote:
> > > --- a/include/linux/mmap_lock.h
> > > +++ b/include/linux/mmap_lock.h
> > > @@ -78,6 +78,37 @@ static inline void mmap_assert_write_locked(const struct mm_struct *mm)
> > …
> > > +/* Only meaningful if CONFIG_LOCK_STAT is defined. */
> > > +#define __vma_lockdep_stat_mark_acquired(vma) \
> > > +   lock_acquired(&vma->vmlock_dep_map, _RET_IP_)
> > > +
> >
> > After going through the remaining series, I don't think I found a
> > matching lock_contended(). So perf/ tracing just give you a few
> > lock-acquired events. Wouldn't it make sense to also some
> > lock_contended() events where the caller had to wait before it could
> > acquire the lock?
>
> Yeah I did wonder about this actually. The series really just abstracts this
> part, so I think doing something with that should be a follow-up.
>
> Suren - what was your intent with this? I did wonder what we actually really
> accomplished with this.
>
> VMA locks are always try-locks.
>
> Write locks can't be contended against one another since VMAs are always a
> per-process entity and not obtained remotely, so either a VMA is write-locked by
> us or not write-locked, never write-locked by anybody else.

Correct, all paths which call __vma_enter_locked() to either
write-lock a vma or to detach it have to already hold the mmap write
lock on vma->vm_mm. So, lock_contended() will never be triggered for
vma write locking paths.

>
> Read locks immediately give up if the VMA is write locked.
>
> Would we want to record a lock_contended() event in that case I guess then?

Yes, we could have it in vma_start_read_locked_nested() if refcount
increment fails and if the refcount != 0 (if it's 0 then the vma is
detached and the refcount can't change concurrently).

>
> I don't think we'd want to do that if the VMA were detached, only if it were
> write-locked?

Yes, that's why we would need an additional check for 0 in there.

I can add this logic after your patchset lands. I don't think we need
to block it for this.
Thanks,
Suren.

>
> >
> > Sebastian
>
> Cheers, Lorenzo