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 03/14] bpf: net: Consider optval.is_bpf before capable check in sock_setsockopt()
Date: Wed, 27 Jul 2022 09:54:08 -0700 [thread overview]
Message-ID: <YuFtsIvDlxh6TwkG@google.com> (raw)
In-Reply-To: <20220727060915.2372520-1-kafai@fb.com>
On 07/26, Martin KaFai Lau wrote:
> When bpf program calling bpf_setsockopt(SOL_SOCKET),
> it could be run in softirq and doesn't make sense to do the capable
> check. There was a similar situation in bpf_setsockopt(TCP_CONGESTION).
Should we instead skip these capability checks based on something like
in_serving_softirq? I wonder if we might be mixing too much into that
is_bpf flag (locking assumptions, context assumptions, etc)?
next prev parent reply other threads:[~2022-07-27 17:48 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
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 [this message]
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=YuFtsIvDlxh6TwkG@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.