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

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

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.

Looking at kmalloc_nolock(), it has this (in_nmi() || in_hardirq())
check on PREEMPT_RT. The reasoning was unconditional raw_spinlock_t
locking and bad lock-owner recording for hardirq.
There was a trylock path for local_lock to make it work from atomic
context. But from what I can tell this goes
  kmalloc_nolock_noprof() -> __slab_alloc_node() -> __slab_alloc() ->
  ___slab_alloc() -> local_lock_cpu_slab()

The last one does local_lock_irqsave() on PREEMPT_RT which does a
spin_lock(). That means atomic context is not possible. Where did I make
a wrong turn? Or did this change recently? I do remember that Alexei
reworked parts of the allocator to make the local_lock based trylock
allocation work.

quoted

Cheers,
Longman

Sebastian