[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1365e2a1-dda9-4aa3-9658-cc34a9bb3137@linux.dev>
Date: Fri, 1 Aug 2025 18:46:59 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Amery Hung <ameryhung@...il.com>, memxor@...il.com
Cc: netdev@...r.kernel.org, alexei.starovoitov@...il.com, andrii@...nel.org,
daniel@...earbox.net, kpsingh@...nel.org, martin.lau@...nel.org,
yonghong.song@...ux.dev, song@...nel.org, haoluo@...gle.com,
kernel-team@...a.com, bpf@...r.kernel.org
Subject: Re: [RFC PATCH bpf-next v1 00/11] Remove task and cgroup local
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.
Powered by blists - more mailing lists