Re: [PATCH v2 6/6] slab: Introduce kmalloc_nolock() and kfree_nolock().

[Vlastimil Babka <vbabka@suse.cz>]

On 7/10/25 12:21, Harry Yoo wrote:
> On Thu, Jul 10, 2025 at 11:36:02AM +0200, Vlastimil Babka wrote:
>> On 7/9/25 03:53, Alexei Starovoitov wrote:
>> 
>> Hm but this is leaking the slab we allocated and have in the "slab"
>> variable, we need to free it back in that case.
> 
> But it might be a partial slab taken from the list?

True.

> Then we need to trylock n->list_lock and if that fails, oh...

So... since we succeeded taking it from the list and thus the spin_trylock,
it means it's safe to spinlock n->list_lock again - we might be waiting on
other cpu to unlock it but we know we didn't NMI on our own cpu having the
lock, right? But we'd probably need to convince lockdep about this somehow,
and also remember if we allocated a new slab or taken on from the partial
list... or just deal with this unlikely situation in another irq work :/

>> >  		c->slab = NULL;
>> >  		c->freelist = NULL;
>> >  		c->tid = next_tid(c->tid);
>