linux-kernel - Re: [PATCH RESEND v3 10/10] mm/vma: add and use vma_assert

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] [day] [month] [year] [list]

Message-ID: <20260123233550.2378-1-hdanton@sina.com>
Date: Sat, 24 Jan 2026 07:35:48 +0800
From: Hillf Danton <hdanton@...a.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Boqun Feng <boqun.feng@...il.com>,
	Waiman Long <longman@...hat.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [PATCH RESEND v3 10/10] mm/vma: add and use vma_assert_stabilised()

On Thu, 22 Jan 2026 13:02:02 +0000 Lorenzo Stoakes wrote:
> +/**
> + * vma_assert_stabilised() - assert that this VMA cannot be changed from
> + * underneath us either by having a VMA or mmap lock held.
> + * @vma: The VMA whose stability we wish to assess.
> + *
> + * If lockdep is enabled we can precisely ensure stability via either an mmap
> + * lock owned by us or a specific VMA lock.
> + *
> + * With lockdep disabled we may sometimes race with other threads acquiring the
> + * mmap read lock simultaneous with our VMA read lock.
> + */
> +static inline void vma_assert_stabilised(struct vm_area_struct *vma)
> +{
> +	/*
> +	 * If another thread owns an mmap lock, it may go away at any time, and
> +	 * thus is no guarantee of stability.
> +	 *
> +	 * If lockdep is enabled we can accurately determine if an mmap lock is
> +	 * held and owned by us. Otherwise we must approximate.
> +	 *
> +	 * It doesn't necessarily mean we are not stabilised however, as we may
> +	 * hold a VMA read lock (not a write lock as this would require an owned
> +	 * mmap lock).
> +	 *
> +	 * If (assuming lockdep is not enabled) we were to assert a VMA read
> +	 * lock first we may also run into issues, as other threads can hold VMA
> +	 * read locks simlutaneous to us.
> +	 *
> +	 * Therefore if lockdep is not enabled we risk a false negative (i.e. no
> +	 * assert fired). If accurate checking is required, enable lockdep.
> +	 */
> +	if (IS_ENABLED(CONFIG_LOCKDEP)) {
> +		if (lockdep_is_held(&vma->vm_mm->mmap_lock))
> +			return;
> +	} else {
> +		if (rwsem_is_locked(&vma->vm_mm->mmap_lock))
> +			return;
> +	}
In case of the mmap_lock, rwsem_is_locked has nothing to do with lockdep_is_held,
as the latter is noop without lockdep enabled. And the former fails to match the
us in "assert that this VMA cannot be changed from underneath us either by having
a VMA or mmap lock held".

That said, you are adding confusion.
> +
> +	/*
> +	 * We're not stabilised by the mmap lock, so assert that we're
> +	 * stabilised by a VMA lock.
> +	 */
> +	vma_assert_locked(vma);
> +}
> +