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

[Levi Zim <i@kxxt.dev>]

On 5/13/26 9:42 AM, Harry Yoo (Oracle) wrote:
> On Tue, May 12, 2026 at 09:46:33PM +0800, Levi Zim wrote:
>> On 5/12/26 8:25 PM, Harry Yoo (Oracle) wrote:
>>> Hello everybody. This is a follow-up discussion of
>>> "kmalloc_nolock() follow-ups, including kfree_rcu_nolock()" topic at
>>> LSFMMBPF 2026 last week. Unfortunately, many RCU folks were not there,
>>> but we can still discuss over email ;)
>>>
>>> The slides: https://docs.google.com/presentation/d/1kpaLd7D1dwRvIqRwQfSjJVVJL0CC2gwb-AV56yCMqXw/edit?usp=sharing
>>>
>>> I'm copying the slides here to make it easier to reply.
> 
> [...]
> 
>>> The end goal
>>> ============
>>>
>>> - Drop the BPF memory allocator
>>> - Avoid preallocation as much as possible in BPF
>>> - Use kmalloc_nolock() and kfree_{,rcu_}nolock() (and friends) instead
>>
>> By using kmalloc_nolock, a regression happens on architectures without HAVE_CMPXCHG_DOUBLE.
>> For reference, currently only x86, arm64, s390 and loongarch selects HAVE_CMPXCHG_DOUBLE
>>
>> For example, this has already caused bpf_task_storage_get with flag
>> BPF_LOCAL_STORAGE_GET_F_CREATE to always fail on riscv64 6.19 kernel.
> 
> Ouch.
> 
>> I attempted to fix it in https://lists.infradead.org/pipermail/linux-riscv/2026-March/087159.html,
>> but as pointed out in the threads, the approach is not sound.
>>
>> After that, I thought about using the BPF memory allocator instead of kmalloc_nolock on such
>> architectures to fix it. But I haven't got time to implement it.
> 
> Oh please, let's not go in that direction :)
> 
>> 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.

The commit message says that the allocation may still fail if the slab lock
acquisition fails upon the first try. But this is still a great improvement
compared to the previous always failing code.

Thanks,
Levi