[mptcp-net 0/2] mptcp: fix for issue/121
by Paolo Abeni
The mentioned issues is fixed by any of this 2 patches.
The first one is a minimal fix that could land to stable,
the second one addresses the an underlaying state-management
bug, which needs some more complex changes.
The plan is to send them both to -net.
Paolo Abeni (2):
mptcp: more strict state checking for acks
mptcp: better msk-level shutdown.
net/mptcp/protocol.c | 64 +++++++++++++-------------------------------
1 file changed, 18 insertions(+), 46 deletions(-)
--
2.26.2
9 months, 2 weeks
[MPTCP][PATCH v2 mptcp-next 0/3] mptcp: create subflow for newly added address and testcases
by Geliang Tang
v2:
- drop the unused addr parameter in mptcp_nl_add_subflow_or_signal_addr
- use the pernet *_max values in mptcp_pm_create_subflow_or_signal_addr
instead of the per-msk values.
Address issue 19 "let PM netlink update live sockets on local addresses
list change". The removed addresses part of this issue is done, this
patchset only implemented the added addresses part.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/19
Geliang Tang (3):
mptcp: create subflow or signal addr for newly added address
selftests: mptcp: use minus value for removing address numbers
selftests: mptcp: add testcases for newly added addresses
net/mptcp/pm_netlink.c | 43 ++++++--
.../testing/selftests/net/mptcp/mptcp_join.sh | 101 +++++++++++++++---
2 files changed, 123 insertions(+), 21 deletions(-)
--
2.29.2
9 months, 2 weeks
[PATCH] linux: handle MPTCP consistently with TCP
by Paolo Abeni
The MPTCP protocol uses a specific protocol value, even if
it's an extension to TCP. Additionally, MPTCP sockets
could 'fall-back' to TCP at run-time, depending on peer MPTCP
support and available resources.
As a consequence of the specific protocol number, selinux
applies the raw_socket class to MPTCP sockets.
Existing TCP application converted to MPTCP - or forced to
use MPTCP socket with user-space hacks - will need an
updated policy to run successfully.
This change lets selinux attach the TCP socket class to
MPTCP sockets, too, so that no policy changes are needed in
the above scenario.
Note that the MPTCP is setting, propagating and updating the
security context on all the subflows and related request
socket.
Link: https://lore.kernel.org/linux-security-module/CAHC9VhTaK3xx0hEGByD2zxfF7f...
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
security/selinux/hooks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6fa593006802..451bded67d9c 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1120,7 +1120,8 @@ static inline u16 inode_mode_to_security_class(umode_t mode)
static inline int default_protocol_stream(int protocol)
{
- return (protocol == IPPROTO_IP || protocol == IPPROTO_TCP);
+ return (protocol == IPPROTO_IP || protocol == IPPROTO_TCP ||
+ protocol == IPPROTO_MPTCP);
}
static inline int default_protocol_dgram(int protocol)
--
2.26.2
9 months, 2 weeks
[PATCH net] net: mptcp: cap forward allocation to 1M
by Davide Caratti
the following syzkaller reproducer:
r0 = socket$inet_mptcp(0x2, 0x1, 0x106)
bind$inet(r0, &(0x7f0000000080)={0x2, 0x4e24, @multicast2}, 0x10)
connect$inet(r0, &(0x7f0000000480)={0x2, 0x4e24, @local}, 0x10)
sendto$inet(r0, &(0x7f0000000100)="f6", 0xffffffe7, 0xc000, 0x0, 0x0)
systematically triggers the following warning:
WARNING: CPU: 2 PID: 8618 at net/core/stream.c:208 sk_stream_kill_queues+0x3fa/0x580
Modules linked in:
CPU: 2 PID: 8618 Comm: syz-executor Not tainted 5.10.0+ #334
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/04
RIP: 0010:sk_stream_kill_queues+0x3fa/0x580
Code: df 48 c1 ea 03 0f b6 04 02 84 c0 74 04 3c 03 7e 40 8b ab 20 02 00 00 e9 64 ff ff ff e8 df f0 81 2
RSP: 0018:ffffc9000290fcb0 EFLAGS: 00010293
RAX: ffff888011cb8000 RBX: 0000000000000000 RCX: ffffffff86eecf0e
RDX: 0000000000000000 RSI: ffffffff86eecf6a RDI: 0000000000000005
RBP: 0000000000000e28 R08: ffff888011cb8000 R09: fffffbfff1f48139
R10: ffffffff8fa409c7 R11: fffffbfff1f48138 R12: ffff8880215e6220
R13: ffffffff8fa409c0 R14: ffffc9000290fd30 R15: 1ffff92000521fa2
FS: 00007f41c78f4800(0000) GS:ffff88802d000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95c803d088 CR3: 0000000025ed2000 CR4: 00000000000006f0
Call Trace:
__mptcp_destroy_sock+0x4f5/0x8e0
mptcp_close+0x5e2/0x7f0
inet_release+0x12b/0x270
__sock_release+0xc8/0x270
sock_close+0x18/0x20
__fput+0x272/0x8e0
task_work_run+0xe0/0x1a0
exit_to_user_mode_prepare+0x1df/0x200
syscall_exit_to_user_mode+0x19/0x50
entry_SYSCALL_64_after_hwframe+0x44/0xa9
userspace programs provide arbitrarily high values of 'len' in sendmsg():
this is causing integer overflow of 'amount'. Cap forward allocation to 1
megabyte: higher values are not really useful.
Suggested-by: Paolo Abeni <pabeni(a)redhat.com>
Fixes: e93da92896bc ("mptcp: implement wmem reservation")
Signed-off-by: Davide Caratti <dcaratti(a)redhat.com>
---
net/mptcp/protocol.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 09b19aa2f205..6628d8d74203 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -877,6 +877,9 @@ static void __mptcp_wmem_reserve(struct sock *sk, int size)
struct mptcp_sock *msk = mptcp_sk(sk);
WARN_ON_ONCE(msk->wmem_reserved);
+ if (WARN_ON_ONCE(amount < 0))
+ amount = 0;
+
if (amount <= sk->sk_forward_alloc)
goto reserve;
@@ -1587,7 +1590,7 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
if (msg->msg_flags & ~(MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL))
return -EOPNOTSUPP;
- mptcp_lock_sock(sk, __mptcp_wmem_reserve(sk, len));
+ mptcp_lock_sock(sk, __mptcp_wmem_reserve(sk, min_t(size_t, 1 << 20, len)));
timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
--
2.29.2
9 months, 3 weeks
[PATCH mptcp-next v4 0/3] add IPv4-mapped address support
by Matthieu Baerts
This patchset adds IPv4-mapped address support and testcases.
v4:
- do not try to create subflows between v4 and v6 addresses: with v3, we would
try to do that and it could succeed if the IPv6 address ends with a valid v4
address. See patch 2/3
- add two testcases checking that in 3/3: the 1st one was failing with v3.
- add #ifdef MPTCP_IPV6 in patch 1/3 (Mat)
- split the code I previously sent into two commits to allow backports: to be
checked if they can really be considered as "fixes" or "new features".
- @Geliang: I hope this is OK for you, I quickly did these modifications during
a lunch break and ran mp_join selftests + mpjoin packetdrill. Please tell me
if I did anything wrong :)
v3:
- add Matt's code in it.
- deal with the IPv4-mapped back to IPv4 case too.
- add two new IPv4-mapped back to IPv4 testcases.
v2:
- v1 calls mptcp_pm_addr_convert_v4mapped in mptcp_pm_nl_add_addr_received,
on the receiving side. v2 calls it in select_signal_address, on the
sending side.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122
Geliang Tang (1):
selftests: mptcp: add IPv4-mapped IPv6 testcases
Matthieu Baerts (2):
mptcp: support MPJoin with IPv4 mapped in v6 sk
mptcp: pm nl: support IPv4 mapped in v6 addresses
net/mptcp/pm_netlink.c | 37 ++++++----
net/mptcp/subflow.c | 24 +++++--
.../testing/selftests/net/mptcp/mptcp_join.sh | 67 +++++++++++++++++++
3 files changed, 109 insertions(+), 19 deletions(-)
--
2.29.2
10 months
[MPTCP][PATCH v2 mptcp-next 0/2] add IPv4-mapped address support
by Geliang Tang
This patchset added the IPv4-mapped address support and the testcases.
v2:
- v1 calls mptcp_pm_addr_convert_v4mapped in mptcp_pm_nl_add_addr_received,
on the receiving side. v2 calls it in select_signal_address, on the
sending side.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122
Geliang Tang (2):
mptcp: convert IPv4 address to IPv4-mapped
selftests: mptcp: add IPv4-mapped IPv6 testcases
net/mptcp/pm_netlink.c | 25 ++++++++++++--
.../testing/selftests/net/mptcp/mptcp_join.sh | 34 +++++++++++++++++++
2 files changed, 56 insertions(+), 3 deletions(-)
--
2.29.2
10 months, 1 week
[MPTCP][PATCH v8 mptcp-next 0/8] ADD_ADDR: ports support
by Geliang Tang
v8:
- release the listening socket when removing the entry.
- initialize addr.port and lsk in mptcp_pm_nl_get_local_id().
- change kernel_listen's backlog to 1024.
- enable address_zero's use_port.
v7:
- use the MPTCP listening socket instead of TCP one
- release subflow_req->msk in subflow_init_req
- add mismatched port MIBs
- use sock_common in source_address
v6:
- create and bind the listening socket in mptcp_nl_cmd_add_addr.
- drop the patch "mptcp: add port number listened in kernel check" in
v5.
v5:
- use the per netns listening socket.
- First 8 patches in v4 had been merged to the export branch, drop them
from this patchset.
v4:
- hold msk->pm.lock in mptcp_pm_sport_in_anno_list.
- Merge the patchset 'Squash to "ADD_ADDR: ports support v3"' into v4.
v3:
- add two new patches, 8 and 11
- add more IS_ENABLED(CONFIG_MPTCP_IPV6) in patch 2
- define TCPOLEN_MPTCP_ADD_ADDR_HMAC in patch 4
- add flags check in patch 10
- update the testcases
v2:
- change mptcp_out_options's port field in CPU bype order.
- keep mptcp_options_received's port field in CPU bype order.
- add two new patches to simplify ADD_ADDR suboption writing.
- update mptcp_add_addr_len helper use adding up size.
- add more commit messages.
v1:
This series is the first version of ADD_ADDR ports support. I have solved
the listener problem which I mentioned at the meeting on 15th of October
by adding a new listening socket from the userspace (see patch 8). Up to
now this patchset works well.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/54
Geliang Tang (8):
mptcp: create the listening socket for new port
mptcp: add port number check for MP_JOIN
mptcp: add port number announced check
mptcp: enable use_port when invoke addresses_equal
mptcp: deal with MPTCP_PM_ADDR_ATTR_PORT in PM netlink
selftests: mptcp: add port argument for pm_nl_ctl
mptcp: add the mibs for ADD_ADDR with port
selftests: mptcp: add testcases for ADD_ADDR with port
net/mptcp/mib.c | 6 +
net/mptcp/mib.h | 6 +
net/mptcp/options.c | 4 +
net/mptcp/pm_netlink.c | 100 +++++++++++-
net/mptcp/protocol.c | 2 +-
net/mptcp/protocol.h | 4 +
net/mptcp/subflow.c | 48 +++++-
.../testing/selftests/net/mptcp/mptcp_join.sh | 148 +++++++++++++++++-
tools/testing/selftests/net/mptcp/pm_nl_ctl.c | 24 ++-
9 files changed, 331 insertions(+), 11 deletions(-)
--
2.29.2
10 months, 1 week
[MPTCP][PATCH v3 mptcp-next 0/2] add IPv4-mapped address support
by Geliang Tang
This patchset added the IPv4-mapped address support and the testcases.
v3:
- add Matt's code in it.
- deal with the IPv4-mapped back to IPv4 case too.
- add two new IPv4-mapped back to IPv4 testcases.
v2:
- v1 calls mptcp_pm_addr_convert_v4mapped in mptcp_pm_nl_add_addr_received,
on the receiving side. v2 calls it in select_signal_address, on the
sending side.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122
Geliang Tang (2):
mptcp: convert IPv4 address with IPv4-mapped address
selftests: mptcp: add IPv4-mapped IPv6 testcases
net/mptcp/pm_netlink.c | 21 ++++----
net/mptcp/subflow.c | 22 +++++---
.../testing/selftests/net/mptcp/mptcp_join.sh | 51 +++++++++++++++++++
3 files changed, 78 insertions(+), 16 deletions(-)
--
2.29.2
10 months, 1 week
[Weekly meetings] MoM - 17th of December 2020
by Matthieu Baerts
Hello everyone,
Today, we had our INT8_MAX+2 th meeting with Mat and Ossama (Intel),
Christoph (Apple), Davide, Paolo and Florian (RedHat) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Accepted patches:
- The list of accepted patches can be seen on PatchWork:
https://patchwork.ozlabs.org/project/mptcp/list/?state=3
netdev (if mptcp ML is in cc) (Mat Martineau):
1414602 [net-next,9/9] mptcp: let MPTCP create max size skbs
1414603 [net-next,8/9] mptcp: pm: simplify select_local_address()
1414599 [net-next,7/9] mptcp: parse and act on incoming FASTCLOSE optio
1414600 [net-next,6/9] tcp: parse mptcp options contained in reset pack
1414601 [net-next,5/9] mptcp: hold mptcp socket before calling tcp_done
1414598 [net-next,4/9] mptcp: use MPTCPOPT_HMAC_LEN macro
1414597 [net-next,3/9] selftests: mptcp: add the flush addrs testcase
1414596 [net-next,2/9] mptcp: remove address when netlink flushes addrs
1414595 [net-next,1/9] mptcp: attach subflow socket to parent cgroup
1416290 [v2,net-next] mptcp: clear use_ack and use_map when dropping
other su...
our repo (by: Geliang Tang, Paolo Abeni):
1416111 [mptcp-net] mptcp: properly annotate nested lock
1416006 [mptcp-net,v2] mptcp: fix pending data accounting
1415493 [mptcp-next] Squash to "mptcp: add the address ID assignment
bitmap"
1415026 [mptcp-net] mptcp: fix security context on server socket
1414708 [mptcp-next] Squash to "[PATCH v3 mptcp-next 1/6] mptcp: add
the outg...
1414604 [mptcp-next] Squash-to: "mptcp: push pending frames when
subflow has ...
1413273 [v3,mptcp-next,6/6] selftests: mptcp: add the MP_PRIO testcases
1413272 [v3,mptcp-next,5/6] mptcp: add the mibs for MP_PRIO
1413271 [v3,mptcp-next,4/6] selftests: mptcp: add set_flags command in
1413270 [v3,mptcp-next,3/6] mptcp: add set_flags command in PM netlink
1413269 [v3,mptcp-next,2/6] mptcp: add the incoming MP_PRIO support
1413268 [v3,mptcp-next,1/6] mptcp: add the outgoing MP_PRIO support
1413262 [v4,mptcp-next,2/2] selftests: mptcp: add testcases for setting
1413254 [v4,mptcp-next,1/2] mptcp: add the address ID assignment bitmap
1409622 [RFC] selinux: handle MPTCP consistently with TCP
Pending patches:
- The list of pending patches can be seen on PatchWork:
https://patchwork.ozlabs.org/project/mptcp/list/?state=*
netdev (if mptcp ML is in cc) (by: Paolo Abeni):
1417092 linux: handle MPTCP consistently with TCP
1417085 [net,4/4] mptcp: fix pending data accounting
1417080 [net,3/4] mptcp: push pending frames when subflow has free spac
1417083 [net,2/4] mptcp: properly annotate nested lock
1417079 [net,1/4] mptcp: fix security context on server socket:
- Waiting to be applied upstream
- Done just after the meeting
our repo (by: Florian Westphal, Geliang Tang):
1370700: RFC: [RFC,2/4] tcp: move selected mptcp helpers to tcp.h/mptcp.h
1370702: RFC: [RFC,4/4] tcp: parse tcp options contained in reset packets
1375893: RFC: [RFC,mptpcp-next] mptcp: add ooo prune support
1395128: RFC: [1/5] tcp: make two mptcp helpers available to tcp stack
1395131: RFC: [3/5] mptcp: add mptcp reset option support
1395133: RFC: [5/5] mptcp: send fastclose if userspace closes socket
with unread data:
- WIP
1415495: New: [v8,mptcp-next,1/8] mptcp: create the listening socket for
1415496: New: [v8,mptcp-next,2/8] mptcp: add port number check for MP_JO
1415497: New: [v8,mptcp-next,3/8] mptcp: add port number announced check
1415498: New: [v8,mptcp-next,4/8] mptcp: enable use_port when invoke add
1415499: New: [v8,mptcp-next,5/8] mptcp: deal with MPTCP_PM_ADDR_ATTR_PO
1415500: New: [v8,mptcp-next,6/8] selftests: mptcp: add port argument fo
1415501: New: [v8,mptcp-next,7/8] mptcp: add the mibs for ADD_ADDR with
1415502: New: [v8,mptcp-next,8/8] selftests: mptcp: add testcases for A:
- Waiting for reviews
- Mat will have a look
1416891: Changes Requested: [v2,mptcp-next,1/2] mptcp: convert IPv4
address to IPv4-mapped
1416892: Changes Requested: [v2,mptcp-next,2/2] selftests: mptcp: add
IPv4-mapped IPv6 testcases:
- Changes requested by Mat
- Linked to issue 122 on GH
- Discussions needed:
- Direction taken: modifying entries in the local address
- It seems not "clean": it seems more natural not to modify
stuff for this check, maybe we should change the way the check is done?
- i.e. when comparing addresses, we can check for IPv4 mapped
- @Geliang: would it be OK to take this direction?
1416976: New: [mptcp-next,1/3] mptcp: create subflow or signal addr for
newly added address
1416977: New: [mptcp-next,2/3] selftests: mptcp: use minus value for
removing address numbers
1416978: New: [mptcp-next,3/3] selftests: mptcp: add testcases for newly
added addresses:
- Waiting for reviews
- Mat started to look
- Linked to https://github.com/multipath-tcp/mptcp_net-next/issues/19
- The goal of #19 what to allow the Netlink API to use a new
endpoint (e.g. new WiFi link)
- (Maybe later we can add a flag to disable this behaviour)
- It makes sense to do that and that's what Geliang is doing here,
good!
- But is it OK to do this iteration there in the code at this place?
- Patch:
https://patchwork.ozlabs.org/project/mptcp/patch/73d430a234a018dbef408242...
- Mat might need help for the review on this one
Issues on Github:
https://github.com/multipath-tcp/mptcp_net-next/issues/
Recently opened (latest from last week: 127)
130 [syzkaller] WARNING in mptcp_token_destroy_request [bug]
[syzkaller]:
- no repro yet
129 set subflow socket consistently [bug] [enhancement]:
- When looking at buf autotuning, Paolo found not nice to have
different struct sockets for client/outbound subflows and server/inbound
subflows.
- Sharing a common structure would be nice
- Also, we need to traverse the conn_list to set the NOSPACE bit
on each subflow
- We might want to share this structure for [sg]etsockopt
128 When the last subflow is closed without DATA_FIN and msk
Established, close msk (after a timeout) [enhancement]:
- We might want different behaviours for inbound and outbound
sockets, e.g.:
- client might want to create new subflows over new subflows
even if there is no existing one
- server might want not being stuck and close connections
- MPTCP keep alive might be something different, more advanced
behaviour
- A dedicated timeout might be good for now
- For the moment, we don't have dedicated MPTCP setsockopt,
maybe we can also wait
- sysctl should be there to configure the default value
- should be fine to add new sysctl just for MPTCP if they are
specific
- Or Netlink API but might be more tricky for the end user,
e.g. when forcing some specific app to create MPTCP sockets instead of
TCP one with LD_PRELOAD
Bugs (opened, flagged as "bug" and assigned)
126 [syzkaller] WARNING in mptcp_reset_timer [bug] [syzkaller]
@dcaratti:
- With the repro, we reproduce another issue: 115, all the time :-)
- will fix this one and check this 126 happens again.
- but maybe linked
123 sndmsg autotuning is disable [bug] @pabeni:
- As soon as autotuning is re-enabled, some selftests are failing
(multiple xmit)
- Very difficult to get complete link utilisation (no longer
blocked by buffers)
- Trying to use mptcp.org, Paolo is interested by BLEST
- Min RTT in mptcp.org works fairly well in most scenarios but in
heterogeneous, we might not fully use all links
- sum of the thgput of all subflow * minRTT (?)
- best way to try reaching full speed: set very very large TCP
rcv and snt windows, just to see if we are not blocked because of that
- what Paolo sees is: unstable at the beginning and better later.
So if it is transferring a few small files, it is not great
- Christoph: we need early reinjection. To avoid the packets on
the slow links blocking the whole connection. It is explained there:
https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/...
- The sender is blocked somehow, best is to analyse pcaps
122 PM doesn't create subflow with IPv4 mapped IPv6 socket [bug]
@geliangtang:
- See patches above ↑
94 Packetdrill: after a received DATA_FIN, no new packets can be
treated [bug] [packetdrill] @dcaratti:
- Davide will check if he can still reproduce it
Bugs (opened and flagged as "bug" and not assigned)
130 [syzkaller] WARNING in mptcp_token_destroy_request [bug] [syzkaller]
129 set subflow socket consistently [bug] [enhancement]
127 [syzkaller] WARNING in corrupted [bug] [syzkaller]
125 [syzkaller] KASAN: wild-memory-access Write in
subflow_req_destructor [bug] [syzkaller]
121 [syzkaller] divide error in __tcp_select_window [bug] [syzkaller]
120 [interop] netnext is dropping packets, causing MPTCP-level
retransmissions on mptcp.org [bug]
119 [syzkaller] memory leak in __get_filter [bug] [syzkaller]
115 [syzkaller] WARNING in sk_stream_kill_queues [bug] [syzkaller]
112 sporadic failure of mptcp_join.sh selftest 13 [bug]
110 [syzkaller] memory leak in __ip_mc_join_group [bug] [syzkaller]
107 Review use of WARN_ON() / WARN_ON_ONCE() [bug]
65 clearing properly the status in listen() [bug]
56 msk connection state set without msk lock [bug]
In Progress (opened and assigned)
96 Python: add support for IPPROTO_MPTCP [enhancement] @matttbe
76 [gs]etsockopt per subflow: BPF [enhancement] @matttbe
54 ADD_ADDR: ports support [enhancement] @geliangtang
51 MP_PRIO support [enhancement] @geliangtang
19 let PM netlink update live sockets on local addresses list
change [enhancement] @geliangtang
60 PM: netlink: events per connection [enhancement]
- Florian is working on PM to share events
- the API will not be exactly the same, prefix different
- Florian will try to reduce the modifications
Recently closed (since last week)
124 ./mptcp_connect.sh -m mmap test blocks: regression [bug]
117 Allow user-space to set endpoint ID [enhancement] [help wanted]
@geliangtang
114 packetdrill: dss tolerance issue to emit the FIN+ACK [bug]
[packetdrill]
106 [syzkaller] BUG: Bad page state [bug] [syzkaller]
104 [syzkaller] general protection fault in skb_release_data [bug]
[syzkaller] @geliangtang
67 `./mptcp_connect.sh -m mmap` test blocks [bug]
FYI: Current Roadmap:
- Bugs: https://github.com/multipath-tcp/mptcp_net-next/projects/2
- Current merge window (5.11):
https://github.com/multipath-tcp/mptcp_net-next/projects/6
- For later: https://github.com/multipath-tcp/mptcp_net-next/projects/4
- TODO: 5.12
Patches to send to netdev:
- net:
- everything has been sent
- net-next:
- / (closed)
Extra tests:
- news about Syzkaller? (Christoph):
- See above ↑
- news about interop with mptcp.org? (Christoph):
- /
- news about Intel's kbuild? (Mat):
- Mat confirms it is the same issue he had with selftests, see
the meeting notes from last week
- Mat has more access now, should be easier to retrieve more
details about an issue
- packetdrill (Davide):
- /
- CI (Matth):
- /
Next meeting:
- We cancel the two next ones? → Yes
Next meeting:
- We propose to have the next meeting in 3 weeks, on Thursday, the
7th of January 2021.
- Usual UTC time: 16:00 UTC (8am PST, 5pm CET, Midnight CST)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20210107
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next year,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
10 months, 1 week
[MPTCP][PATCH mptcp-next 0/3] mptcp: create subflow or signal
by Geliang Tang
Address issue 19 "let PM netlink update live sockets on local addresses
list change". The removed addresses part of this issue is done, this
patchset only implemented the added addresses part.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/19
Geliang Tang (3):
mptcp: create subflow or signal addr for newly added address
selftests: mptcp: use minus value for removing address numbers
selftests: mptcp: add testcases for newly added addresses
net/mptcp/pm_netlink.c | 37 ++++++
.../testing/selftests/net/mptcp/mptcp_join.sh | 105 +++++++++++++++---
2 files changed, 125 insertions(+), 17 deletions(-)
--
2.29.2
10 months, 1 week