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.
