[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b51c79c59cb3ec4be95e993be9be2e5d9441670.camel@redhat.com>
Date: Wed, 02 Aug 2023 10:03:12 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>, Geliang Tang
<geliang.tang@...e.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
<daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Martin KaFai
Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, Yonghong Song
<yhs@...com>, John Fastabend <john.fastabend@...il.com>, KP Singh
<kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Hao Luo
<haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, Florent Revest
<revest@...omium.org>, Brendan Jackman <jackmanb@...omium.org>, Matthieu
Baerts <matthieu.baerts@...sares.net>, Mat Martineau
<martineau@...nel.org>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, John
Johansen <john.johansen@...onical.com>, Paul Moore <paul@...l-moore.com>,
James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>, Eric Paris
<eparis@...isplace.org>, Mykola Lysenko <mykolal@...com>, Shuah Khan
<shuah@...nel.org>, bpf@...r.kernel.org, netdev@...r.kernel.org,
mptcp@...ts.linux.dev, apparmor@...ts.ubuntu.com,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [RFC bpf-next v7 0/6] bpf: Force to MPTCP
On Mon, 2023-07-31 at 17:43 -0700, Alexei Starovoitov wrote:
> I still think it's a hack, but its blast radius is nicely contained.
> And since I cannot propose any better I'm ok with it.
>
> Patches 1-2 can be squashed into one.
> Just like patches 3-6 as a single patch for selftests.
>
> But before proceeding I'd like an explicit ack from netdev maintainers.
Just to state the obvious, I carry my personal bias on this topic due
to my background ;)
My perspective is quite similar to Alexei's one: the solution is not
extremely elegant, but is very self-contained; it looks viable to me.
WRT the specific code, I think the additional checks on the 'protocol'
value after the 'update_socket_protocol()' call should be dropped: the
user space can already provide an arbitrary value there and the later
code deal with that.
Cheers,
Paolo
Powered by blists - more mailing lists