Re: [RFC PATCH bpf-next v1 00/11] Remove task and cgroup local

[Martin KaFai Lau <martin.lau@linux.dev>]

On 7/29/25 11:25 AM, Amery Hung wrote:
> Question:
> 
> - In bpf_local_storage_destroy() and bpf_local_storage_map_free(), where
>    it is not allow to fail, I assert that the lock acquisition always
>    succeeds based on the fact that 1) these paths cannot run recursively
>    causing AA deadlock and 2) local_storage->lock and b->lock are always
>    acquired in the same order, but I also notice that rqspinlock has
>    a timeout fallback. Is this assertion an okay thing to do?

At bpf_local_storage_destroy, the task is going away.
At bpf_local_storage_map_free, the map is going away.
A bpf prog needs to have both task ptr and map ptr to be able to do 
bpf_task_storage_get(+create) and bpf_task_storage_delete().

The bpf_local_storage_destroy and bpf_local_storage_map_free can run in 
parallel, and you mentioned there is lock ordering. Not sure how the timeout 
fallback is (Kumar ?) but I don't think either of the two functions will hold a 
lock for a very long time before releasing it.

I also think bpf_local_storage_destroy and bpf_local_storage_map_free should not 
fail. It is good to keep the WARN_ON but I would change it to WARN_ON_ONCE.