[PATCH] mptcp:netlink: fix compilation warning
by Matthieu Baerts
net/mptcp/pm_netlink.c: In function ‘mptcp_pm_nl_add_addr_received’:
net/mptcp/pm_netlink.c:238:23: warning: variable ‘pernet’ set but not used [-Wunused-but-set-variable]
238 | struct pm_nl_pernet *pernet;
| ^~~~~~
Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
---
Notes:
to be squashed in "mptcp: add netlink-based PM"
net/mptcp/pm_netlink.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index 4bab1b32f932..743c3c58f826 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -235,9 +235,6 @@ void mptcp_pm_nl_add_addr_received(struct mptcp_sock *msk)
struct sock *sk = (struct sock *)msk;
struct mptcp_addr_info remote;
struct mptcp_addr_info local;
- struct pm_nl_pernet *pernet;
-
- pernet = net_generic(sock_net((struct sock *)msk), pm_nl_pernet_id);
pr_debug("accepted %d:%d remote family %d",
msk->pm.add_addr_accepted, msk->pm.add_addr_accept_max,
--
2.25.1
2 years, 3 months
[GIT] Sync with net-next on 20200324: conflicts
by Matthieu Baerts
Hello,
Recently, MPTCP-related patch from Davide has been applied in 'net-next'
repo:
- 767d3ded5fb8 (net: mptcp: don't hang before sending 'MP capable with
data')
This created conflicts:
- 02366081040c: conflict in t/mptcp-Add-path-manager-interface
- fc3cbf097321: conflict in
t/mptcp-Add-handling-of-outgoing-MP_JOIN-requests
- 501e7cf63225: conflict in
t/mptcp-update-per-unacked-sequence-on-pkt-reception
- 6ed26433863c..844c9c9ed5a1 -- net/mptcp: result
I hope they have been resolved as expected.
Tests are in progress. The "export" branch will be updated after the tests.
Cheers,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
2 years, 3 months
[PATCH net-next] net: mptcp: don't hang in mptcp_sendmsg() after TCP fallback
by Davide Caratti
it's still possible for packetdrill to hang in mptcp_sendmsg(), when the
MPTCP socket falls back to regular TCP (e.g. after receiving unsupported
flags/version during the three-way handshake). Adjust MPTCP socket state
earlier, to ensure correct functionality of mptcp_sendmsg() even in case
of TCP fallback.
Fixes: 767d3ded5fb8 ("net: mptcp: don't hang before sending 'MP capable with data'")
Fixes: 1954b86016cf ("mptcp: Check connection state before attempting send")
Signed-off-by: Davide Caratti <dcaratti(a)redhat.com>
---
net/mptcp/protocol.c | 4 ----
net/mptcp/subflow.c | 6 ++++++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index e959104832ef..92d5382e71f4 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -1055,10 +1055,6 @@ void mptcp_finish_connect(struct sock *ssk)
WRITE_ONCE(msk->write_seq, subflow->idsn + 1);
WRITE_ONCE(msk->ack_seq, ack_seq);
WRITE_ONCE(msk->can_ack, 1);
- if (inet_sk_state_load(sk) != TCP_ESTABLISHED) {
- inet_sk_state_store(sk, TCP_ESTABLISHED);
- sk->sk_state_change(sk);
- }
}
static void mptcp_sock_graft(struct sock *sk, struct socket *parent)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 052d72a1d3a2..06b9075333c5 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -109,9 +109,15 @@ static void subflow_v6_init_req(struct request_sock *req,
static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
{
struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(sk);
+ struct sock *parent = subflow->conn;
subflow->icsk_af_ops->sk_rx_dst_set(sk, skb);
+ if (inet_sk_state_load(parent) != TCP_ESTABLISHED) {
+ inet_sk_state_store(parent, TCP_ESTABLISHED);
+ parent->sk_state_change(parent);
+ }
+
if (!subflow->conn_finished) {
pr_debug("subflow=%p, remote_key=%llu", mptcp_subflow_ctx(sk),
subflow->remote_key);
--
2.24.1
2 years, 3 months
Additional part 3 squash suggestion
by Mat Martineau
Florian and Matthieu -
From the meeting notes, it looks like "subflow: place further subflows on
new 'join_list'" is the commit that you're planning to squash.
What do you think about also squashing "mptcp: increment MIB counters in a
few places" in to the previous MIB commit? Seems like our patch count for
part 3 is still kind of high.
--
Mat Martineau
Intel
2 years, 3 months
[syzkaller] WARNING: CPU: 0 PID: 17298 at net/mptcp/protocol.c:305 mptcp_reset_timer+0x89/0xb0 net/mptcp/protocol.c:305
by Christoph Paasch
Hello,
I had a syzkaller failure today.
Reproducer is:
# {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1 Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false NetInjection:false NetDevices:false NetReset:false Cgroups:false BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false UseTmpDir:false HandleSegv:false Repro:false Trace:false}
r0 = socket$inet_mptcp(0x2, 0x1, 0x106)
r1 = socket$inet_mptcp(0x2, 0x1, 0x106)
bind$inet(r1, &(0x7f00000013c0)={0x2, 0x4e20, @multicast2}, 0x10)
connect$inet(r1, &(0x7f0000000040)={0x2, 0x0, @loopback}, 0x10)
listen(r1, 0x3)
connect$inet(r0, &(0x7f0000000040)={0x2, 0x4e20, @loopback}, 0x4d)
sendmsg$inet(r0, &(0x7f0000000280)={0x0, 0x0, &(0x7f0000000000)=[{&(0x7f0000000080)="ff", 0x20000081}], 0x1}, 0x0)
The panic:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 17298 at net/mptcp/protocol.c:305 mptcp_reset_timer+0x89/0xb0 net/mptcp/protocol.c:305
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 17298 Comm: syz-executor.5 Not tainted 5.6.0-rc5 #61
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x150/0x1a0 lib/dump_stack.c:118
panic+0x2de/0x725 kernel/panic.c:221
__warn.cold+0x2f/0x33 kernel/panic.c:582
report_bug+0x291/0x300 lib/bug.c:195
fixup_bug arch/x86/kernel/traps.c:174 [inline]
fixup_bug arch/x86/kernel/traps.c:169 [inline]
do_error_trap+0x10a/0x1b0 arch/x86/kernel/traps.c:267
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
invalid_op+0x1e/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:mptcp_reset_timer+0x89/0xb0 net/mptcp/protocol.c:305
Code: 80 3c 10 00 75 2d 48 8b 15 04 8b e9 00 49 8d b4 24 08 04 00 00 4c 89 e7 48 01 da e8 c1 cc 99 ff 5b 41 5c 5d c3 e8 27 55 0a fe <0f> 0b bb 14 00 00 00 eb b3 48 c7 c7 00 90 40 84 e8 c2 66 3a fe eb
RSP: 0018:ffffc9001328f070 EFLAGS: 00010212
RAX: 0000000000040000 RBX: 0000000000000000 RCX: ffffc9000321d000
RDX: 0000000000007bc8 RSI: ffffffff83570519 RDI: 0000000000000007
RBP: ffffc9001328f080 R08: ffff88803cf77000 R09: ffffed1006c3ff8d
R10: ffffed1006c3ff8c R11: ffff8880361ffc67 R12: ffff8880361ff700
R13: 4dc1477c1c2da268 R14: ffff8880361ff834 R15: ffff88801fe71c00
mptcp_data_acked+0x28/0x330 net/mptcp/protocol.c:312
update_una net/mptcp/options.c:778 [inline]
mptcp_incoming_options+0xdc0/0x14f0 net/mptcp/options.c:849
tcp_data_queue+0xe8a/0x4870 net/ipv4/tcp_input.c:4777
tcp_rcv_established+0x8d4/0x1d20 net/ipv4/tcp_input.c:5727
tcp_v4_do_rcv+0x60f/0x8c0 net/ipv4/tcp_ipv4.c:1621
sk_backlog_rcv include/net/sock.h:996 [inline]
__release_sock+0x1a6/0x310 net/core/sock.c:2448
release_sock+0x59/0x1b0 net/core/sock.c:2964
sk_stream_wait_memory+0x641/0xfc0 net/core/stream.c:145
do_tcp_sendpages+0x8fd/0x1e80 net/ipv4/tcp.c:1068
mptcp_sendmsg_frag+0x1418/0x1f00 net/mptcp/protocol.c:560
mptcp_sendmsg+0x541/0xe60 net/mptcp/protocol.c:739
inet_sendmsg+0x9e/0xe0 net/ipv4/af_inet.c:807
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg net/socket.c:672 [inline]
sock_write_iter+0x309/0x490 net/socket.c:1004
call_write_iter include/linux/fs.h:1901 [inline]
do_iter_readv_writev+0x57c/0x830 fs/read_write.c:693
do_iter_write fs/read_write.c:998 [inline]
do_iter_write+0x184/0x600 fs/read_write.c:979
vfs_writev+0x1b3/0x2f0 fs/read_write.c:1071
do_writev+0x2ac/0x330 fs/read_write.c:1114
__do_sys_writev fs/read_write.c:1187 [inline]
__se_sys_writev fs/read_write.c:1184 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1184
do_syscall_64+0xf3/0x570 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fdb995b3469
Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ff 49 2b 00 f7 d8 64 89 01 48
RSP: 002b:00007fdb99ca3dd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 000000000066bf00 RCX: 00007fdb995b3469
RDX: 0000000000000001 RSI: 00000000200001c0 RDI: 0000000000000003
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000d19
R13: 000000000041c19f R14: 00007fdb99ca45c0 R15: 0000000000000003
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 1 seconds..
C reproducer is attached.
This is on top of the export-branch, 624ef4177659 ("mptcp: re-check dsn before reading from subflow").
Cheers,
Christoph
2 years, 3 months
Preparing to send "part 3" - cover letter draft
by Mat Martineau
Here's my draft for the cover letter.
Paolo, is the path manager part correct? Anything I should add there?
Note that I proposed "netdev-v1-for-5.6" for the tag because there's an
existing "netdev-v1-part3" tag, although that "part 3" patch set was never
sent to netdev (it was combined with the part 2 posting) - we can use the
v1-part3 tag if people prefer that.
"""
Multipath TCP: Multiple subflows and path management
This patch set allows more than one TCP subflow to be established and used
for a multipath TCP connection. Subflows are added to an existing
connection using the MP_JOIN option during the 3-way handshake. With
multiple TCP subflows available, sent data is now stored in the MPTCP
socket so it may be retransmitted on any TCP subflow if there is no
DATA_ACK before a timeout. If an MPTCP-level timeout occurs, data is
retransmitted using an available subflow. Storing this sent data requires
the addition of memory accounting at the MPTCP level, which was previously
delegated to the single subflow. Incoming DATA_ACKs now free data from the
MPTCP-level retransmit buffer.
IP addresses available for new subflow connections can now be advertised
and received with the ADD_ADDR option, and the corresponding REMOVE_ADDR
option likewise advertises that an address is no longer available.
The MPTCP path manager netlink interface has commands to set in-kernel
limits for the number of concurrent subflows and control the advertisement
of IP addresses between peers.
To track and debug MPTCP connections there are new MPTCP MIB counters, and
subflow context can be requested using inet_diag. The MPTCP self-tests now
validate multiple-subflow operation and the netlink path manager
interface.
Clone/fetch:
https://github.com/multipath-tcp/mptcp_net-next.git (tag:
netdev-v1-for-5.6)
Browse:
https://github.com/multipath-tcp/mptcp_net-next/tree/netdev-v1-for-5.6
Thank you for your review. You can find us at mptcp(a)lists.01.org and
https://is.gd/mptcp_upstream
"""
--
Mat Martineau
Intel
2 years, 3 months
[PATCH net-next] mptcp: Remove set but not used variable 'can_ack'
by YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
net/mptcp/options.c: In function 'mptcp_established_options_dss':
net/mptcp/options.c:338:7: warning:
variable 'can_ack' set but not used [-Wunused-but-set-variable]
commit dc093db5cc05 ("mptcp: drop unneeded checks")
leave behind this unused, remove it.
Signed-off-by: YueHaibing <yuehaibing(a)huawei.com>
---
net/mptcp/options.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 63c8ee49cef2..8ba34950241c 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -335,7 +335,6 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
struct mptcp_sock *msk;
unsigned int ack_size;
bool ret = false;
- bool can_ack;
u8 tcp_fin;
if (skb) {
@@ -364,7 +363,6 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
/* passive sockets msk will set the 'can_ack' after accept(), even
* if the first subflow may have the already the remote key handy
*/
- can_ack = true;
opts->ext_copy.use_ack = 0;
msk = mptcp_sk(subflow->conn);
if (!READ_ONCE(msk->can_ack)) {
2 years, 3 months
[PATCH 0/2] Correctly handle port field in ADD_ADDR option
by Peter Krystad
Existing code allows ADD_ADDR option lengths that include the port field,
so we should correctly parse options with those lengths.
Peter Krystad (2):
mptcp: Parse optional port field of ADD_ADDR
mptcp: Include ADD_ADDR port value for path manager
include/linux/tcp.h | 1 +
net/mptcp/options.c | 11 +++++++++++
2 files changed, 12 insertions(+)
--
2.17.2
2 years, 3 months
[PATCH v1 0/5] squash and cleanup
by Paolo Abeni
This series contains a "squashable" version of:
subflow: place further subflows on new 'join_list'
and a bunch of minor cleanup (unneeded check after not so recent net-next
changes)
Rebased tree available at:
https://github.com/pabeni/mptcp/tree/mptcp_net-next_part3_14
this supersede the squashed branch posted previously.
Self-tests loop running. Will update here with results.
options.c | 11 +++--------
protocol.c | 31 ++++++++++++++++++++++++++++++-
protocol.h | 2 ++
subflow.c | 5 ++++-
4 files changed, 39 insertions(+), 10 deletions(-)
2 years, 3 months
