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
| ||
|
Date: Wed, 27 Jul 2022 09:47:25 -0700 From: sdf@...gle.com To: Martin KaFai Lau <kafai@...com> Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, David Miller <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, kernel-team@...com, Paolo Abeni <pabeni@...hat.com> Subject: Re: [PATCH bpf-next 02/14] bpf: net: Avoid sock_setsockopt() taking sk lock when called from bpf On 07/26, Martin KaFai Lau wrote: > Most of the codes in bpf_setsockopt(SOL_SOCKET) are duplicated from > the sock_setsockopt(). The number of supported options are > increasing ever and so as the duplicated codes. > One issue in reusing sock_setsockopt() is that the bpf prog > has already acquired the sk lock. sockptr_t is useful to handle this. > sockptr_t already has a bit 'is_kernel' to handle the kernel-or-user > memory copy. This patch adds a 'is_bpf' bit to tell if sk locking > has already been ensured by the bpf prog. Why not explicitly call it is_locked/is_unlocked? I'm assuming, at some point, we can have code paths in bpf where the socket has been already locked by the stack?
Powered by blists - more mailing lists