linux-kernel - Re: [PATCH v3 06/10] mm/vma: clean up __vma_enter/exit

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: <20260122125529.1f4a1806fd918155e0a5824b@linux-foundation.org>
Date: Thu, 22 Jan 2026 12:55:29 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 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>, Sebastian Andrzej
 Siewior <bigeasy@...utronix.de>, Clark Williams <clrkwllms@...nel.org>,
 Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v3 06/10] mm/vma: clean up __vma_enter/exit_locked()

On Thu, 22 Jan 2026 12:15:20 -0800 Suren Baghdasaryan <surenb@...gle.com> wrote:

> > +       /* vma should remain attached. */
> > +       if (locked)
> > +               WARN_ON_ONCE(__vma_exit_exclusive_locked(vma));
> 
> I'm wary of calling functions from WARN_ON_ONCE() statements. If
> someone decides to replace WARN_ON_ONCE() with VM_WARN_ON_ONCE(), the
> call will disappear when CONFIG_DEBUG_VM=n. Maybe I'm being paranoid
> but it's because I have been bitten by that before...

Yes please.  The elision is desirable if the function has no side-effects, but
__vma_exit_exclusive_locked() changes stuff.

Someone(tm) should check for this.  A pathetically partial grep turns
up plenty of things:

mm/slab_common.c:	if (head && !WARN_ON_ONCE(!poll_state_synchronize_rcu_full(&head_gp_snap)))
mm/slab_common.c:	if (!WARN_ON_ONCE(!poll_state_synchronize_rcu_full(&bnode->gp_snap))) {
mm/page-writeback.c:		WARN_ON_ONCE(atomic_long_add_return(delta,
mm/page_isolation.c:		WARN_ON_ONCE(!pageblock_unisolate_and_move_free_pages(zone, page));
mm/page_alloc.c:	VM_WARN_ONCE(get_pageblock_isolate(page),
mm/numa_memblks.c:	WARN_ON(memblock_clear_hotplug(0, max_addr));
mm/numa_memblks.c:	WARN_ON(memblock_set_node(0, max_addr, &memblock.memory, NUMA_NO_NODE));
mm/numa_memblks.c:	WARN_ON(memblock_set_node(0, max_addr, &memblock.reserved,
mm/zsmalloc.c:		WARN_ON(!zpdesc_trylock(zpdesc));