Re: [PATCH] irqchip/gic-v3-its: Don't acquire rt_spin_lock in allocate_vpe_l1_table()

[Waiman Long]

On 1/14/26 12:59 PM, Vlastimil Babka wrote:
> On 1/13/26 12:55, Sebastian Andrzej Siewior wrote:
> > On 2026-01-12 12:14:30 [-0500], Waiman Long wrote:
> > > On 1/12/26 10:09 AM, Thomas Gleixner wrote:
> > > > 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.
>
> > > 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