[PATCH] squash-to: "mptcp: recvmsg() can drain data from multiple subflows"
by Davide Caratti
checkpatch fixes
Signed-off-by: Davide Caratti <dcaratti(a)redhat.com>
---
net/mptcp/protocol.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index b9eed120913f..fd89075bd1c9 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -359,7 +359,8 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
desc.count = min_t(size_t, len - copied, map_remaining);
pr_debug("reading %zu bytes, copied %d", desc.count,
copied);
- bytes_read = tcp_read_sock(ssk, &desc, mptcp_read_actor);
+ bytes_read = tcp_read_sock(ssk, &desc,
+ mptcp_read_actor);
if (bytes_read < 0) {
if (!copied)
copied = bytes_read;
--
2.23.0
2 years, 6 months
[PATCH] squash-to: "mptcp: Write MPTCP DSS headers to outgoing data packets"
by Davide Caratti
checkpatch fixes
Signed-off-by_ Davide Caratti <dcaratti(a)redhat.com>
---
net/mptcp/options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 672f7f1288f8..c9b5f37db63b 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -309,7 +309,7 @@ bool mptcp_established_options(struct sock *sk, struct sk_buff *skb,
if (mptcp_established_options_mp(sk, &opt_size, remaining, opts))
ret = true;
else if (mptcp_established_options_dss(sk, skb, &opt_size, remaining,
- opts))
+ opts))
ret = true;
/* we reserved enough space for the above options, and exceeding the
--
2.23.0
2 years, 6 months
[RFC PATCH 0/4] mptcp: [try to] fix armegaddon on late tcp fallback
by Paolo Abeni
Passive connection can fallback to TCP after that the subflow is established.
That leads to disaster in several nasty ways.
Address the issue explicitly falling back to TCP (converting the socket) as
soon as we notice the unsuccessful MPC hanshake completion.
Sent as a very early RFC - completely untested yet.
Paolo Abeni (4):
mptcp: add helper to forcefully fallback the msk socket to TCP
mptcp: cache the first subflow sock
mptcp: late fallback support
mptcp: deal with fallback in additional places.
net/mptcp/protocol.c | 92 +++++++++++++++++++++++++++++++++++++-------
net/mptcp/protocol.h | 1 +
2 files changed, 79 insertions(+), 14 deletions(-)
--
2.21.0
2 years, 6 months
[PATCH v2 1/4] MAINTAINERS: Add MPTCP maintainers
by Mat Martineau
Possible other lines include:
L: mptcp(a)lists.01.org
The issue with including this ML is that it currently rejects messages
from non-subscribers. I can reconfigure the ML, the tradeoff is in
forwarding spam to subscribers.
Q: https://patchwork.ozlabs.org/project/mptcp/list/
It might be confusing for patches to end up in two patchworks (netdev
and mptcp).
T: git git://github.com/multipath-tcp/mptcp_net-next.git
I've seen two main models for net subsystem management:
netdev-based (TCP, TLS): Patches are sent to netdev, approved by
subsystem maintainers, and approved and applied by David Miller.
subtree (netfilter, BPF, bluetooth, wireless): Messages are sent to
netdev (netfilter/BPF) or a separate ML (bluetooth, wireless) and are
approved and merged to separate git repositories by subsystem
maintainers. Those maintainers then send pull requests for batches of
commits to netdev for David Miller to merge directly in git.
The scope of MPTCP seems more like the other netdev-based projects, so
for changes going directly upstream I've proposed MAINTAINERS entries
that match that development model. If we opt to use our own git repo to
merge upstream changes and then send pull requests, then we would
include the "T:" entry for our github repo.
squashto: mptcp: Add MPTCP to skb extensions
Signed-off-by: Mat Martineau <mathew.j.martineau(a)linux.intel.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8608724835dd..97a922599b78 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11538,6 +11538,15 @@ F: net/ipv6/calipso.c
F: net/netfilter/xt_CONNSECMARK.c
F: net/netfilter/xt_SECMARK.c
+NETWORKING [MPTCP]
+M: Mat Martineau <mathew.j.martineau(a)linux.intel.com>
+M: Matthieu Baerts <matthieu.baerts(a)tessares.net>
+L: netdev(a)vger.kernel.org
+W: https://github.com/multipath-tcp/mptcp_net-next/wiki
+B: https://github.com/multipath-tcp/mptcp_net-next/issues
+S: Maintained
+F: include/net/mptcp.h
+
NETWORKING [TCP]
M: Eric Dumazet <edumazet(a)google.com>
L: netdev(a)vger.kernel.org
--
2.24.0
2 years, 6 months
[PATCH 0/2] kselftests: remove modif in framework + commit msg
by Matthieu Baerts
As discussed yesterday, better to remove the modifications we did in
the kselftest framework [1]. While looking at it, I propose to add more
details in the commit message.
[1] https://patchwork.kernel.org/patch/11204935/
Matthieu Baerts (2):
Revert "selftests: settings: tests can be in subsubdirs"
.topmsg: mptcp: add basic kselftest for mptcp
.topmsg | 18 ++++++++++++------
tools/testing/selftests/kselftest/runner.sh | 2 +-
2 files changed, 13 insertions(+), 7 deletions(-)
--
2.24.0
2 years, 6 months
Re: MPTCP implementation feedback for RFC6824bis
by Christoph Paasch
Hello Alan,
there is one more thing that came up from the implementation experience (thanks to Matthieu & Paolo in CC).
It is unclear in the draft (or at least, I didn't find the text ;-) ), what to do when the flags & version in the third ACK + MP_CAPABLE are inconsistent with what was negotiated in the SYN-SYN/ACK exchange.
It would be good to spell this out and say that if there are any inconsistencies, a host should simply fallback to regular TCP.
Christoph
> On Dec 10, 2019, at 8:09 AM, Alan Ford <alan.ford(a)gmail.com> wrote:
>
> Hi Yoshifumi,
>
>> On 10 Dec 2019, at 05:30, Yoshifumi Nishida <nsd.ietf(a)gmail.com <mailto:nsd.ietf@gmail.com>> wrote:
>>
>> Hi Alan,
>>
>> The texts look fine to me, but I have a few questions on them.
>>
>> On Fri, Dec 6, 2019 at 7:58 AM Alan Ford <alan.ford(a)gmail.com <mailto:alan.ford@gmail.com>> wrote:
>> Hi all,
>>
>> Following on from the discussion of implementation feedback with Christoph, I propose the following edits to RFC6824bis - which is currently in AUTH48 - as clarifications.
>>
>> ADs, please can you confirm you consider these edits sufficiently editorial to fit into AUTH48.
>>
>> WG participants, please speak up if you have any concerns.
>>
>>
>> Edit 1, clarifying reliability of MP_CAPABLE
>>
>> Change the sentence reading:
>>
>> The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
>>
>> To:
>>
>> The SYN with MP_CAPABLE occupies the first octet of data sequence space, and this MUST be acknowledged at the connection level at or before the time the first data is sent or received (see Section 3.3).
>>
>> What implementations should do when they receive the first data before MP_CAPABLE is acked?
>> They should terminate the connection or discard the data?
>
> By asking this question you have made me realise that this text is in fact incompatible with the case when A (the initiator) is also the first sender of data.
>
> Given the problem is only with B sending data first, let us forget this change, and revert to Christoph’s original problem text, and use only the below change:
>
>> Change the sentence reading:
>>
>> If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3).
>>
>> To:
>>
>> If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space).
>
> This will resolve the ambiguity in the case of B sending first.
>
>> In my personal opinion either one of these edits would be sufficient for making the point, however clearly this has caused some confusion amongst the implementor community so making both these changes should make it absolutely clear as to the expected behaviour here.
>>
>>
>> Edit 2, mapping constraint
>>
>> Change the sentence reading:
>>
>> A Data Sequence Mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
>>
>> To:
>>
>> A Data Sequence Mapping MUST appear on a TCP segment which is covered by the mapping. It does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
>>
>>
>> What implementations should do when a Data Sequence Mapping doesn't cover the TCP segment that carries this option?
>
> There are a number of cases where the MUST does not have a consequence; it should be obvious from the text for similar failures that it can close it with a RST.
>
>> BTW, This is not a strong opinion, but I may prefer a text like: "A Data Sequence Mapping MUST provide the mapping for the segment that carries this option.”
>
> OK how about: "A Data Sequence Mapping MUST provide the mapping which includes the segment that carries this option.”
>
> Regards,
> Alan
>
>
2 years, 6 months
[PATCH 0/2] Optimize struct mptcp_options_received
by Peter Krystad
Changes for part 1 commits. Conflicts are straightforward
when squashed.
Peter Krystad (2):
mptcp: Move struct mptcp_options_received
mptcp: Remove version field from mptcp_options_received
include/linux/tcp.h | 19 +++++++++++--------
net/mptcp/options.c | 7 ++++---
net/mptcp/protocol.h | 2 ++
3 files changed, 17 insertions(+), 11 deletions(-)
--
2.17.2
2 years, 6 months
[PATCH] Squash-to-mptcp-Create-SUBFLOW-socket-for-incoming-connections
by Paolo Abeni
Need to explicitly clear msk->subflow on passive connection, or
it will inherit the listener msk value, which is uncorrect
This fixes hang-up pre-v1 patches.
Still investigating why the v1 code did non hang without this.
---
net/mptcp/protocol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 87d66842f7fa..11c6b1678169 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -280,6 +280,7 @@ static struct sock *mptcp_accept(struct sock *sk, int flags, int *err,
msk = mptcp_sk(new_mptcp_sock);
msk->remote_key = subflow->remote_key;
msk->local_key = subflow->local_key;
+ msk->subflow = NULL;
newsk = new_mptcp_sock;
mptcp_copy_inaddrs(newsk, ssk);
--
2.21.0
2 years, 6 months
[PATCH] mptcp: Remove version field from subflow_request_sock
by Peter Krystad
This field is not used. Version checking is performed in
mptcp_parse_options().
squashto: Create SUBFLOW socket for incoming connections
Signed-off-by: Peter Krystad <peter.krystad(a)linux.intel.com>
---
net/mptcp/protocol.h | 3 +--
net/mptcp/subflow.c | 4 ----
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 3ac8cb7f38fd..b43fa3ec5d23 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -56,8 +56,7 @@ struct mptcp_subflow_request_sock {
struct tcp_request_sock sk;
u8 mp_capable : 1,
mp_join : 1,
- backup : 1,
- version : 4;
+ backup : 1;
u64 local_key;
u64 remote_key;
};
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 9f148d19ee10..1874e41066bb 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -43,10 +43,6 @@ static void subflow_init_req(struct request_sock *req,
if (rx_opt.mptcp.mp_capable && listener->request_mptcp) {
subflow_req->mp_capable = 1;
- if (rx_opt.mptcp.version >= listener->request_version)
- subflow_req->version = listener->request_version;
- else
- subflow_req->version = rx_opt.mptcp.version;
subflow_req->remote_key = rx_opt.mptcp.sndr_key;
}
}
--
2.17.2
2 years, 6 months
[PATCH] mptcp: only orphan partially subflow at close time
by Paolo Abeni
This close the following race
CPU 0 CPU 1
sock_orphan()
// SOCK_DEAD
tcp_done()
inet_csk_destroy_sock()
sock_put()
tcp_close()
// UAF
Note that we can't simply acquire an additional ref to the
sock before sock_orphan() and releasing it after close,
such ref will be consumed by inet_csk_destroy_sock when
the race is triggered.
Squash-to: "mptcp: Handle MP_CAPABLE options for outgoing connections"
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
net/mptcp/protocol.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 9506e04a2010..24d68e504e9c 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -178,8 +178,16 @@ static void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,
/* outgoing subflow */
sock_release(sock);
} else {
- /* incoming subflow */
- sock_orphan(ssk);
+ /* This is an incoming subflow. We almost orphan it,
+ * but do not mark has death, otherwise inet_csk_destroy_sock
+ * may kick-in via tcp_done() and steal one reference
+ * before tcp_close below.
+ */
+ write_lock_bh(&sk->sk_callback_lock);
+ sk_set_socket(sk, NULL);
+ sk->sk_wq = NULL;
+ write_unlock_bh(&sk->sk_callback_lock);
+
tcp_close(ssk, timeout);
}
}
--
2.21.0
2 years, 6 months
