On Tue, Dec 01, 2020 at 06:04:50PM -0800, Andrii Nakryiko wrote: > On Tue, Dec 1, 2020 at 6:49 AM Kuniyuki Iwashima <kuniyu@xxxxxxxxxxxx> wrote: > > > > This commit adds 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, the kernel runs it for socket migration > > only if the expected_attach_type is BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. > > The kernel will change the behaviour depending on the returned value: > > > > - SK_PASS with selected_sk, select it as a new listener > > - SK_PASS with selected_sk NULL, fall back to the random selection > > - SK_DROP, cancel the migration > > > > Link: https://lore.kernel.org/netdev/20201123003828.xjpjdtk4ygl6tg6h@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > Suggested-by: Martin KaFai Lau <kafai@xxxxxx> > > Signed-off-by: Kuniyuki Iwashima <kuniyu@xxxxxxxxxxxx> > > --- > > include/uapi/linux/bpf.h | 2 ++ > > kernel/bpf/syscall.c | 8 ++++++++ > > tools/include/uapi/linux/bpf.h | 2 ++ > > 3 files changed, 12 insertions(+) > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index 85278deff439..cfc207ae7782 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -241,6 +241,8 @@ enum bpf_attach_type { > > BPF_XDP_CPUMAP, > > BPF_SK_LOOKUP, > > BPF_XDP, > > + BPF_SK_REUSEPORT_SELECT, > > + BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, > > __MAX_BPF_ATTACH_TYPE > > }; > > > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > > index f3fe9f53f93c..a0796a8de5ea 100644 > > --- a/kernel/bpf/syscall.c > > +++ b/kernel/bpf/syscall.c > > @@ -2036,6 +2036,14 @@ bpf_prog_load_check_attach(enum bpf_prog_type prog_type, > > if (expected_attach_type == BPF_SK_LOOKUP) > > return 0; > > return -EINVAL; > > + case BPF_PROG_TYPE_SK_REUSEPORT: > > + switch (expected_attach_type) { > > + case BPF_SK_REUSEPORT_SELECT: > > + case BPF_SK_REUSEPORT_SELECT_OR_MIGRATE: > > + return 0; > > + default: > > + return -EINVAL; > > + } > > this is a kernel regression, previously expected_attach_type wasn't > enforced, so user-space could have provided any number without an > error. I also think this change alone will break things like when the usual attr->expected_attach_type == 0 case. At least changes is needed in bpf_prog_load_fixup_attach_type() which is also handling a similar situation for BPF_PROG_TYPE_CGROUP_SOCK. I now think there is no need to expose new bpf_attach_type to the UAPI. Since the prog->expected_attach_type is not used, it can be cleared at load time and then only set to BPF_SK_REUSEPORT_SELECT_OR_MIGRATE (probably defined internally at filter.[c|h]) in the is_valid_access() when "migration" is accessed. When "migration" is accessed, the bpf prog can handle migration (and the original not-migration) case. > > > case BPF_PROG_TYPE_EXT: > > if (expected_attach_type) > > return -EINVAL; > > diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h > > index 85278deff439..cfc207ae7782 100644 > > --- a/tools/include/uapi/linux/bpf.h > > +++ b/tools/include/uapi/linux/bpf.h > > @@ -241,6 +241,8 @@ enum bpf_attach_type { > > BPF_XDP_CPUMAP, > > BPF_SK_LOOKUP, > > BPF_XDP, > > + BPF_SK_REUSEPORT_SELECT, > > + BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, > > __MAX_BPF_ATTACH_TYPE > > }; > > > > -- > > 2.17.2 (Apple Git-113) > >
