From: sdf@google.com
To: Martin KaFai Lau <kafai@fb.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
David Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
kernel-team@fb.com, Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH bpf-next 02/14] bpf: net: Avoid sock_setsockopt() taking sk lock when called from bpf
Date: Wed, 27 Jul 2022 09:47:25 -0700 [thread overview]
Message-ID: <YuFsHaTIu7dTzotG@google.com> (raw)
In-Reply-To: <20220727060909.2371812-1-kafai@fb.com>
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?
next prev parent reply other threads:[~2022-07-27 17:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 6:08 [PATCH bpf-next 00/14] bpf: net: Remove duplicated codes from bpf_setsockopt() Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 01/14] net: Change sock_setsockopt from taking sock ptr to sk ptr Martin KaFai Lau
2022-07-27 8:11 ` David Laight
2022-07-27 20:42 ` Martin KaFai Lau
2022-07-27 8:16 ` Eric Dumazet
2022-07-27 18:50 ` Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 02/14] bpf: net: Avoid sock_setsockopt() taking sk lock when called from bpf Martin KaFai Lau
2022-07-27 8:36 ` David Laight
2022-07-27 20:05 ` Martin KaFai Lau
2022-07-27 16:47 ` sdf [this message]
2022-07-27 18:37 ` Martin KaFai Lau
2022-07-27 20:39 ` Stanislav Fomichev
2022-07-27 21:21 ` Martin KaFai Lau
2022-07-27 21:38 ` Stanislav Fomichev
2022-07-28 0:45 ` Martin KaFai Lau
2022-07-28 1:49 ` Jakub Kicinski
2022-07-28 16:31 ` Martin KaFai Lau
2022-07-28 16:56 ` Jakub Kicinski
2022-07-28 17:20 ` Martin KaFai Lau
2022-07-28 17:40 ` Jakub Kicinski
2022-07-29 10:04 ` David Laight
2022-07-29 19:06 ` Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 03/14] bpf: net: Consider optval.is_bpf before capable check in sock_setsockopt() Martin KaFai Lau
2022-07-27 16:54 ` sdf
2022-07-27 18:47 ` Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 04/14] bpf: net: Avoid do_tcp_setsockopt() taking sk lock when called from bpf Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 05/14] bpf: net: Avoid do_ip_setsockopt() " Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 06/14] bpf: net: Avoid do_ipv6_setsockopt() " Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 07/14] bpf: Embed kernel CONFIG check into the if statement in bpf_setsockopt Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 08/14] bpf: Change bpf_setsockopt(SOL_SOCKET) to reuse sock_setsockopt() Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 09/14] bpf: Refactor bpf specific tcp optnames to a new function Martin KaFai Lau
2022-07-27 6:09 ` [PATCH bpf-next 10/14] bpf: Change bpf_setsockopt(SOL_TCP) to reuse do_tcp_setsockopt() Martin KaFai Lau
2022-07-27 6:10 ` [PATCH bpf-next 11/14] bpf: Change bpf_setsockopt(SOL_IP) to reuse do_ip_setsockopt() Martin KaFai Lau
2022-07-27 6:10 ` [PATCH bpf-next 12/14] bpf: Change bpf_setsockopt(SOL_IPV6) to reuse do_ipv6_setsockopt() Martin KaFai Lau
2022-07-27 6:10 ` [PATCH bpf-next 13/14] bpf: Add a few optnames to bpf_setsockopt Martin KaFai Lau
2022-07-27 6:10 ` [PATCH bpf-next 14/14] selftests/bpf: bpf_setsockopt tests Martin KaFai Lau
2022-07-27 17:14 ` [PATCH bpf-next 00/14] bpf: net: Remove duplicated codes from bpf_setsockopt() Jakub Kicinski
2022-07-27 20:42 ` Martin KaFai Lau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YuFsHaTIu7dTzotG@google.com \
--to=sdf@google.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kafai@fb.com \
--cc=kernel-team@fb.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.