On 1/14/26 12:59 PM, Vlastimil Babka wrote:

On 1/13/26 12:55, Sebastian Andrzej Siewior wrote:

quoted

On 2026-01-12 12:14:30 [-0500], Waiman Long wrote:

quoted

On 1/12/26 10:09 AM, Thomas Gleixner wrote:

quoted

They might be acquired though. Only alloc_pages_nolock() guarantees that
no lock is taken IIRC.

Thanks for the suggestion. I will look into using that for page allocation.
I had actually attempt to use kmalloc_nolock() to replace kzalloc()
initially. Even though it removed the call to rmqueue(), but there were
other spinlocks in the slub code that were still being acquired like the
local_lock() or the spinlock in the get_random() code. So I gave up using

Hmm if get_random() code takes a spinlock, we have an unsolved
incompatibility with kmalloc_nolock() and CONFIG_SLAB_FREELIST_RANDOM.

quoted

quoted

that. Anyway, kmalloc_nolock() doesn't seem to be fully working yet.

with kmalloc_nolock() you have to be able to deal with a NULL pointer.

Yes. So even after we fix the current problems with incompatible context, I
think kmalloc_nolock() would still be a bad fit for hw bringup code that
should not really fail. Because the possibility of failure will always
exist. The BPF use case that motivated it is quite different.

Yes, it is an issue too that kmalloc_nolock() may fail. If that happens, 
we don't have another good alternative.

Cheers,
Longman