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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [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.