Re: kmalloc_nolock() follow-ups, including kfree_rcu_nolock()

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 5/14/26 11:25, Harry Yoo (Oracle) wrote:
> On Wed, May 13, 2026 at 09:34:01PM +0800, Levi Zim wrote:
>> On 5/13/26 9:42 AM, Harry Yoo (Oracle) wrote:
>> > On Tue, May 12, 2026 at 09:46:33PM +0800, Levi Zim wrote:
>> >> I don't know how could we fix it otherwise after removing BPF memory allocator completely.
>> >> Could we find a path to move forward without causing regressions on architectures without HAVE_CMPXCHG_DOUBLE?
>> > 
>> > Probably we can. Could you please see if this works for you?
>> > 
>> > https://git.kernel.org/pub/scm/linux/kernel/git/harry/linux.git/log/?h=slab-kmalloc-nolock-without-cmpxchg-double-rfc-v1r1-wip
>> 
>> Thanks a lot! I tested it and could confirm that it could fix the failure of
>> bpf_task_storage_get(BPF_LOCAL_STORAGE_GET_F_CREATE) on riscv64.
> 
> Thanks for confirming!
> 
> I will add this to TODO and post them and Cc you when submitting it to
> the mailing list.
> 
>> The commit message says that the allocation may still fail if the slab lock
>> acquisition fails upon the first try.
> 
> kmalloc_nolock() can always fail, unfortunately.
> We can only make it less likely to fail.

There's still the fallback to the larger bucket, right?
That pretty much guarantees that if we fail due to a local lock in one
bucket (due to preempting its holder), a local lock in another bucket won't
be locked at the same time.
However if local sheaves are exhausted, we might need a shared lock (barn,
list_lock, slab bit lock when no double cmpxchg) and that might be held by
another cpu in both buckets. But should be very rare.

>> But this is still a great improvement
>> compared to the previous always failing code.
> 
> Yup. Thanks!
>