Re: [PATCH mm-hotfixes v2 0/2] mm/page_alloc,slab: return NULL early from *_nolock() memory allocation APIs in NMI on UP

[Harry Yoo (Oracle)]

On Mon, Apr 27, 2026 at 10:00:16AM +0200, Vlastimil Babka (SUSE) wrote:
> On 4/27/26 09:09, Harry Yoo (Oracle) wrote:
> > Due to my mistake, V1 was sent twice w/o proper cover letter and
> > Cc: stable. Please ignore V1. Apologies for the noise. 
> > 
> > Changes since V1:
> > - used b4 to send patch series (w/ a proper cover letter) instead of
> >   my broken git send-email script (Thanks Vlastimil)
> > - added Cc: stable to patches 1 and 2
> > 
> > On UP kernels (!CONFIG_SMP), spin_trylock() is a no-op that
> > unconditionally succeeds even when the lock is already held.
> > As a result, alloc_frozen_pages_nolock() and kmalloc_nolock() called
> > from an NMI context can successfully re-acquire the lock that the
> > page/slab allocators are already holding (no deadlock because it's
> > trylock,  but leads to e.g., allocating the same page/object twice and
> > causing use-after-free).
> > 
> > It was discovered while testing the new kmalloc/kfree_nolock() test case
> > in the slub_kunit test module with CONFIG_DEBUG_SPINLOCK=y on a UP
> > kernel.
> > 
> > Patch 1 fixes alloc_frozen_pages_nolock() and
> > patch 2 fixes kmalloc_nolock().
> 
> Thanks. Given the problem exposed is in a slab kunit test I think it's
> better to handle this in the slab tree.

Ack, I'm fine either way.

> The page_alloc change is small and
> should not cause conflicts.

Right.

> So I've merged both in slab/for-next.

Thanks! (I see it's been added to slab/for-next-fixes)

-- 
Cheers,
Harry / Hyeonggon