Re: [linus:master] [mm/vmalloc] a061578043: BUG:spinlock_trylock_failure_on_UP_on_CPU

[Vlastimil Babka <vbabka@suse.cz>]

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.