lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <49f5a594-3db7-fb99-1083-7df1155d3357@linux.dev> Date: Fri, 11 Aug 2023 11:50:17 -0700 From: Martin KaFai Lau <martin.lau@...ux.dev> To: Geliang Tang <geliang.tang@...e.com> Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, 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>, Paolo Abeni <pabeni@...hat.com>, 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>, Simon Horman <horms@...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: [PATCH bpf-next v11 2/5] selftests/bpf: Use random netns name for mptcp On 8/11/23 2:29 AM, Geliang Tang wrote: > On Thu, Aug 10, 2023 at 10:53:38PM -0700, Martin KaFai Lau wrote: >> On 8/9/23 1:19 AM, Geliang Tang wrote: >>> On Tue, Aug 08, 2023 at 11:03:30PM -0700, Martin KaFai Lau wrote: >>>> On 8/6/23 11:40 PM, Geliang Tang wrote: >>>>> On Fri, Aug 04, 2023 at 05:23:32PM -0700, Martin KaFai Lau wrote: >>>>>> On 8/3/23 10:07 PM, Geliang Tang wrote: >>>>>>> Use rand() to generate a random netns name instead of using the fixed >>>>>>> name "mptcp_ns" for every test. >>>>>>> >>>>>>> By doing that, we can re-launch the test even if there was an issue >>>>>>> removing the previous netns or if by accident, a netns with this generic >>>>>>> name already existed on the system. >>>>>>> >>>>>>> Note that using a different name each will also help adding more >>>>>>> subtests in future commits. >>>>> >>>>> Hi Martin, >>>>> >>>>> I tried to run mptcp tests simultaneously, and got "Cannot create >>>>> namespace file "/var/run/netns/mptcp_ns": File exists" errors sometimes. >>>>> So I add this patch to fix it. >>>>> >>>>> It's easy to reproduce, just run this commands in multiple terminals: >>>>> > for i in `seq 1 100`; do sudo ./test_progs -t mptcp; done >>>> >>>> Not only the "-t mptcp" test. Other tests in test_progs also don't support >>>> running parallel in multiple terminals. Does it really help to test the bpf >>>> part of the prog_tests/mptcp.c test by running like this? If it wants to >>>> exercise the other mptcp networking specific code like this, a separate >>>> mptcp test is needed outside of test_progs and it won't be run in the bpf >>>> CI. >>>> >>>> If you agree, can you please avoid introducing unnecessary randomness to the >>>> test_progs where bpf CI and most users don't run in this way? >>> >>> Thanks Martin. Sure, I agree. Let's drop this patch. >> >> Thanks you. >> >>>> I have a high level question. In LPC 2022 >>>> (https://lpc.events/event/16/contributions/1354/), I recall there was idea >>>> in using bpf to make other mptcp decision/policy. Any thought and progress >>>> on this? This set which only uses bpf to change the protocol feels like an >>>> incomplete solution. >>> >>> We are implementing MPTCP packet scheduler using BPF. Patches aren't >>> sent to BPF mail list yet, only temporarily on our mptcp repo[1]. >>> >>> Here are the patches: >>> >>> selftests/bpf: Add bpf_burst test >>> selftests/bpf: Add bpf_burst scheduler >>> bpf: Export more bpf_burst related functions >>> selftests/bpf: Add bpf_red test >>> selftests/bpf: Add bpf_red scheduler >>> selftests/bpf: Add bpf_rr test >>> selftests/bpf: Add bpf_rr scheduler >>> selftests/bpf: Add bpf_bkup test >>> selftests/bpf: Add bpf_bkup scheduler >>> selftests/bpf: Add bpf_first test >>> selftests/bpf: Add bpf_first scheduler >>> selftests/bpf: Add bpf scheduler test >>> selftests/bpf: add two mptcp netns helpers >>> selftests/bpf: use random netns name for mptcp >>> selftests/bpf: Add mptcp sched structs >>> bpf: Add bpf_mptcp_sched_kfunc_set >>> bpf: Add bpf_mptcp_sched_ops >>> >>> If you could take a look at these patches in advance, I would greatly >>> appreciate it. Any feedback is welcome. >>> >>> [1] >>> https://github.com/multipath-tcp/mptcp_net-next.git >> >> Thanks for sharing. I did not go into the details. iiuc, the scheduler is >> specific to a namespace. Do you see if it is useful to have more finer >> control like depending on what IP address it is connected to? BPF policy is >> usually found more useful to have finer policy control than global or >> per-netns. >> >> The same question goes for the fmod_ret here in this patch. The >> progs/mptcpify.c selftest is as good as upgrading all TCP connections. Is it >> your only use case and no need for finer selection? > > This per-netns control is just the first step. We do need finer selection. The > most ideal mode is to select one app to upgrade it's TCP connections only. So > per-cgroup control is much better than per-netns. But we haven't found a good > per-cgroup solution yet. Selecting an app or cgroup can sort of be done by getting the current task or current cgroup (there is helper to do that). I am imagining eventually it will want to decide the protocol upgrade and/or the mptcp-scheduler when the destination IP is decided. This fmod_ret upgrade for all acts like a global knob (sysctl) and feels like a hack or at least incomplete. However, I also don't see a clean way to do that for now in the current shape. Please respin another revision to address the earlier selftest comment on the netns name. Thanks.
Powered by blists - more mailing lists