Files
rockchip-kernel/include/uapi/linux
Kuniyuki Iwashima d5e4ddaeb6 bpf: Support socket migration by eBPF.
This patch introduces a new bpf_attach_type for BPF_PROG_TYPE_SK_REUSEPORT
to check if the attached eBPF program is capable of migrating sockets. When
the eBPF program is attached, we run it for socket migration if the
expected_attach_type is BPF_SK_REUSEPORT_SELECT_OR_MIGRATE or
net.ipv4.tcp_migrate_req is enabled.

Currently, the expected_attach_type is not enforced for the
BPF_PROG_TYPE_SK_REUSEPORT type of program. Thus, this commit follows the
earlier idea in the commit aac3fc320d ("bpf: Post-hooks for sys_bind") to
fix up the zero expected_attach_type in bpf_prog_load_fixup_attach_type().

Moreover, this patch adds a new field (migrating_sk) to sk_reuseport_md to
select a new listener based on the child socket. migrating_sk varies
depending on if it is migrating a request in the accept queue or during
3WHS.

  - accept_queue : sock (ESTABLISHED/SYN_RECV)
  - 3WHS         : request_sock (NEW_SYN_RECV)

In the eBPF program, we can select a new listener by
BPF_FUNC_sk_select_reuseport(). Also, we can cancel migration by returning
SK_DROP. This feature is useful when listeners have different settings at
the socket API level or when we want to free resources as soon as possible.

  - SK_PASS with selected_sk, select it as a new listener
  - SK_PASS with selected_sk NULL, fallbacks to the random selection
  - SK_DROP, cancel the migration.

There is a noteworthy point. We select a listening socket in three places,
but we do not have struct skb at closing a listener or retransmitting a
SYN+ACK. On the other hand, some helper functions do not expect skb is NULL
(e.g. skb_header_pointer() in BPF_FUNC_skb_load_bytes(), skb_tail_pointer()
in BPF_FUNC_skb_load_bytes_relative()). So we allocate an empty skb
temporarily before running the eBPF program.

Suggested-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/netdev/20201123003828.xjpjdtk4ygl6tg6h@kafai-mbp.dhcp.thefacebook.com/
Link: https://lore.kernel.org/netdev/20201203042402.6cskdlit5f3mw4ru@kafai-mbp.dhcp.thefacebook.com/
Link: https://lore.kernel.org/netdev/20201209030903.hhow5r53l6fmozjn@kafai-mbp.dhcp.thefacebook.com/
Link: https://lore.kernel.org/bpf/20210612123224.12525-10-kuniyu@amazon.co.jp
2021-06-15 18:01:06 +02:00
..
2021-01-25 18:44:44 +01:00
2020-05-28 11:22:14 +02:00
2020-12-28 14:21:31 +00:00
2019-12-18 18:07:31 +01:00
2021-02-09 10:58:19 +01:00
2020-08-12 10:58:00 -07:00
2020-10-09 12:47:02 -06:00
2021-06-15 18:01:06 +02:00
2021-03-04 17:58:15 -08:00
2020-12-08 15:54:16 +01:00
2019-10-09 22:31:14 -04:00
2019-09-25 17:51:39 -07:00
2020-04-27 16:29:41 +05:30
2020-07-19 19:20:22 -07:00
2020-06-24 21:34:11 +02:00
2020-05-14 16:44:25 +02:00
2020-05-28 22:09:47 -04:00
2021-02-08 13:01:24 +01:00
2020-07-13 15:32:56 -07:00
2020-04-20 12:43:24 -07:00
2020-07-24 17:12:41 -07:00
2020-08-27 07:55:59 -07:00
2021-02-26 09:41:03 -08:00
2021-03-23 23:40:55 -04:00
2020-11-26 14:19:10 +01:00
2020-05-21 08:20:35 -06:00
2020-03-29 22:30:57 -07:00
2021-03-10 09:34:06 +01:00
2020-08-18 15:44:44 +02:00
2021-01-24 14:43:45 +01:00
2021-04-02 14:21:50 -07:00
2019-10-02 20:32:27 -06:00
2020-03-29 22:30:57 -07:00
2021-01-16 23:19:26 +01:00
2021-03-10 09:34:06 +01:00
2019-12-18 18:07:31 +01:00
2021-01-07 16:17:32 +01:00
2019-12-09 09:59:07 +01:00
2020-03-29 23:29:08 +02:00
2020-10-23 11:55:28 -04:00
2020-10-23 11:55:28 -04:00
2020-07-13 15:32:56 -07:00
2020-06-24 07:51:01 +02:00