linux-kernel - Re: [PATCH mm-hotfixes] mm: remove unnecessary and incorrect mmap lock 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: <fdcf51d1-9aa8-463b-82e6-97d6efe3750d@kernel.org>
Date: Wed, 14 Jan 2026 13:35:05 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: "Liam R . Howlett" <Liam.Howlett@...cle.com>,
 Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
 Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
 SeongJae Park <sj@...nel.org>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, Chris Mason <clm@...a.com>
Subject: Re: [PATCH mm-hotfixes] mm: remove unnecessary and incorrect mmap
 lock assert

On 1/14/26 12:56, Lorenzo Stoakes wrote:
> This check was introduced by commit 42fc541404f2 ("mmap locking API: add
> mmap_assert_locked() and mmap_assert_write_locked()") which replaced a
> VM_BUG_ON_VMA() over rwsem_is_locked from commit a00cc7d9dd93 ("mm, x86:
> add support for PUD-sized transparent hugepages"), i.e. the commit that
> introduced PUD THPs.
> 
> These seem to be careful asserts introduced to ensure that locks are held
> in general, however for a zap we require that VMAs are kept stable, and
> this is a requirement that has held perfectly well for a long time.
> 
> These were long before VMA locks and thus there appears to be no reason to
> think this is assert is there for anything other than 'stabilised VMA'.
> 
> Asserting that the VMA under examination is stable only in the case of a
> THP PUD is strange and unnecessary. If we wish to be careful and assert
> such things, we should do so at the zap level.
> 
> However in any case the current situation is already simply incorrect - a
> VMA lock suffices here.
> 
> Remove the assert for now as it is unnecessarily, incorrect and unhelpful,
> subsequent work can introduce an assert in general for zapping if required.
> 
> Fixes: 2ab7f1bbafc9 ("mm/madvise: allow guard page install/remove under VMA lock")
> Reported-by: Chris Mason <clm@...a.com>
> Closes: https://lore.kernel.org/all/20260113220856.2358195-1-clm@meta.com/
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>

Makes sense to me

Acked-by: David Hildenbrand (Red Hat) <david@...nel.org>

-- 
Cheers

David