linux-kernel - Re: [linus:master] [mm/vmalloc] a061578043: BUG:spinlock_trylock_failure_on_UP_on

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: <5a1721bc-e7e8-40e8-b2b9-c071d18a0112@suse.cz>
Date: Mon, 22 Dec 2025 17:11:13 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Matthew Wilcox <willy@...radead.org>,
 kernel test robot <oliver.sang@...el.com>
Cc: Vishal Moola <vishal.moola@...il.com>, oe-lkp@...ts.linux.dev,
 lkp@...el.com, linux-kernel@...r.kernel.org,
 Andrew Morton <akpm@...ux-foundation.org>,
 Uladzislau Rezki <urezki@...il.com>, linux-mm@...ck.org,
 Mel Gorman <mgorman@...hsingularity.net>
Subject: Re: [linus:master] [mm/vmalloc] a061578043:
 BUG:spinlock_trylock_failure_on_UP_on_CPU

On 12/20/25 00:37, Matthew Wilcox wrote:
> On Fri, Dec 19, 2025 at 08:26:14PM +0000, Matthew Wilcox wrote:
>> Now, as I recall, we are very much doing this on purpose.  We decided
>> not to disable interrupts at this point for improved interrupt
>> latency, accepting the possibility that we'd occasionally fail
>> the trylock.  Except on UP that's now an assertion failure.

IIRC the primary motivation wasn't irq latency, it was to avoid IPIs for
remote drains. So the drain_pages_zone() can be in fact locking pcp of
another cpu, and any local operations on that cpu are then supposed to fail
their trylock (should be relatively rare). Disabling irqs would then make no
sense for protecting other cpu.

> This is stupid and wrong.  If we have CONFIG_SMP=n and
> CONFIG_DEBUG_SPINLOCK=n, then trylock always succeeds.  And we'll end
> up corrupting the data structure protected by the lock.  So the warning
> is real, and we need to fix this.

That seems to be true and we should probably be doing spin_lock_irqsave() on
UP instead of spin_lock() in drain_pages_zone() and several other places.
Ideally via some wrappers like we have for the trylock operations that also
do some UP-specific stuff - pcp_spin_trylock() and pcp_spin_trylock().

> With my distro hat on, I do not give two hoots.  We don't ship a nosmp
> kernel.  I suspect all other distros (except maybe something targetting
> m68k?) are in the same boat.

Yeah seems the problem was introduced at 6.2 with commit 574907741599
("mm/page_alloc: leave IRQs enabled for per-cpu page allocations") or
something around that.

I'm off until Jan 5th so won't be developing a fix until then, but agree it
doesn't seem that urgent now.