[PATCH net-next v2 00/15] Multipath TCP part 2: Single subflow
by Mat Martineau
v1 -> v2: Rebased on latest "Multipath TCP: Prerequisites" v3 series
This set adds MPTCP connection establishment, writing & reading MPTCP
options on data packets, a sysctl to allow MPTCP per-namespace, and self
tests. This is sufficient to establish and maintain a connection with a
MPTCP peer, but will not yet allow or initiate establishment of
additional MPTCP subflows.
Clone/fetch:
https://github.com/multipath-tcp/mptcp_net-next.git (tag: netdev-v2-part2)
Browse:
https://github.com/multipath-tcp/mptcp_net-next/tree/netdev-v2-part2
Thank you for your review. You can find us at mptcp(a)lists.01.org and
https://is.gd/mptcp_upstream
Florian Westphal (2):
mptcp: add subflow write space signalling and mptcp_poll
mptcp: add basic kselftest for mptcp
Mat Martineau (3):
mptcp: Add MPTCP socket stubs
mptcp: Write MPTCP DSS headers to outgoing data packets
mptcp: Implement MPTCP receive path
Matthieu Baerts (1):
mptcp: new sysctl to control the activation per NS
Paolo Abeni (2):
mptcp: recvmsg() can drain data from multiple subflows
mptcp: allow collapsing consecutive sendpages on the same substream
Peter Krystad (7):
mptcp: Handle MPTCP TCP options
mptcp: Associate MPTCP context with TCP socket
mptcp: Handle MP_CAPABLE options for outgoing connections
mptcp: Create SUBFLOW socket for incoming connections
mptcp: Add key generation and token tree
mptcp: Add shutdown() socket operation
mptcp: Add setsockopt()/getsockopt() socket operations
MAINTAINERS | 2 +
include/linux/tcp.h | 34 +
include/net/mptcp.h | 98 ++
net/Kconfig | 1 +
net/Makefile | 1 +
net/ipv4/tcp.c | 2 +
net/ipv4/tcp_input.c | 19 +-
net/ipv4/tcp_output.c | 57 +
net/ipv6/tcp_ipv6.c | 7 +
net/mptcp/Kconfig | 16 +
net/mptcp/Makefile | 4 +
net/mptcp/crypto.c | 122 ++
net/mptcp/ctrl.c | 130 ++
net/mptcp/options.c | 520 ++++++++
net/mptcp/protocol.c | 1159 +++++++++++++++++
net/mptcp/protocol.h | 220 ++++
net/mptcp/subflow.c | 763 +++++++++++
net/mptcp/token.c | 195 +++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/net/mptcp/.gitignore | 2 +
tools/testing/selftests/net/mptcp/Makefile | 13 +
tools/testing/selftests/net/mptcp/config | 2 +
.../selftests/net/mptcp/mptcp_connect.c | 832 ++++++++++++
.../selftests/net/mptcp/mptcp_connect.sh | 595 +++++++++
tools/testing/selftests/net/mptcp/settings | 1 +
25 files changed, 4795 insertions(+), 1 deletion(-)
create mode 100644 net/mptcp/Kconfig
create mode 100644 net/mptcp/Makefile
create mode 100644 net/mptcp/crypto.c
create mode 100644 net/mptcp/ctrl.c
create mode 100644 net/mptcp/options.c
create mode 100644 net/mptcp/protocol.c
create mode 100644 net/mptcp/protocol.h
create mode 100644 net/mptcp/subflow.c
create mode 100644 net/mptcp/token.c
create mode 100644 tools/testing/selftests/net/mptcp/.gitignore
create mode 100644 tools/testing/selftests/net/mptcp/Makefile
create mode 100644 tools/testing/selftests/net/mptcp/config
create mode 100644 tools/testing/selftests/net/mptcp/mptcp_connect.c
create mode 100755 tools/testing/selftests/net/mptcp/mptcp_connect.sh
create mode 100644 tools/testing/selftests/net/mptcp/settings
--
2.24.1
2 years, 6 months
Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
by V Anil Kumar
Hi Christoph,
On 12/13/19 11:54 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
>
> On 13/12/19 - 23:41:25, V Anil Kumar wrote:
> > Hi Christoph,
> >
> > Thanks again for your reply. My response is given inline.
> >
> > On 12/13/19 09:59 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > > > On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> > > >
> > > >
> > >
> > >
> > > >
> > > > Hi Christoph,
> > > >
> > > > Thanks for your reply. Please see inline.
> > > >
> > > > On 12/12/19 12:52 AM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > On Dec 10, 2019, at 12:04 PM, V Anil Kumar
> > > > > > <anil@csir4pi.in(javascript:main.compose()> wrote:
> > > > > >
> > > > > >
> > > > > > Hi Alan,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Please see inline.
> > > > > >
> > > > > > On 12/06/19 09:28 PM,Alan
> > > > > > Ford<alan.ford@gmail.com(javascript:main.compose()> 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).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > As far as I understand, the proposed change introduces a “MUST” to
> > > > > > insist that the map in a segment must cover at least some data in
> > > > > > the segment. But the document does not talk anything about the
> > > > > > rational behind it. I guess it is purely an
> > > > > >
> > > > > > ease of implementation?
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > For two reasons:
> > > > >
> > > > > 1. Ease of implementation 2. If an implementation tries to
> > > > > "remember" early mappings, it is not clear how many of these an
> > > > > implementation can hold. Thus, the sender does not know how many
> > > > > early mappings he can send. So, it is hard for a sender to do the
> > > > > right thing.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I think the design/format of the Data Sequence Mapping permits the
> > > > > > map to stand independent of the data being carried in a segment.
> > > > > > So, as long as an implementation is willing to deal with the
> > > > > > complexity of storing and processing late and early mappings (with
> > > > > > respect to the data arrival), it could be permitted provided that
> > > > > > the received map is for an in-window data.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > What is the concrete use-case for such early mappings? What are the
> > > > > benefits of it? I think that if we want to enable such
> > > > > implementation-complexity, we need a compelling use-case with a big
> > > > > benefit.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > Consider a case where a MPTCP connection consists of two subflows, and
> > > > the data segments are scheduled for transmission in the order shown
> > > > below below.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Subflow-1: segment-1 segment-3 segment-5 segment-6
> > > >
> > > > bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600
> > > >
> > > > no map map for 1-100 map for 401-600 no map
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Subflow-2: segment-2 segment-4 segment-7 segment-8
> > > >
> > > > bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800
> > > >
> > > > map for 101-200 map for 301-400 map for 601-800 no map
> > > >
> > > >
> > > >
> > > > In the above case, the map for data in segment-1 is included in
> > > > segment-3.
> > > >
> > > >
> > > >
> > >
> > >
> > > The question here is why would the stack not put the mapping for segment
> > > 1 on segment 1 itself. And what is the benefit of doing so?
> > >
> > >
> > >
> > >
> > >
> >
> > Well it could just be due to the lack of option space insegment-1. For
> > example, the sender ofsegment-1 at that instant wants to transmit multiple
> > TCP options (e.g.timestamp, SACK, DSS and ADD_ADDR). Obviously, they all
> > cannot fit into optionfield of one segment, and eventually the DSS
> > transmission got slightly delayedby a segment or two.
>
> The implementation needs to enforce a strict priority of DSS over SACK and ADD_ADDR.
>
TCP options have evolved over a period of time, and I do not think as such any document/guidelines exist on enforcing priority for one over the other, though it turns out be an interesting topic. Also, more TCP options could come up in future for implementing new features. So, it is likely that implementations would follow different strategy when it come to option priority.
>
>
>
> If the ADD_ADDR does not fit in the TCP-option space, it can send the
> ADD_ADDR on a pure ACK. The echo-bit in the ADD_ADDR guarantee the reliable
> delivery of it.
>
I noticed this new feature in RFC 6824-bis to deliver ADD_ADDR in pure ACK and still achieve the reliability. The ability to deliver MPTCP options in pure ACK will be useful, especially for options like ADD_ADDR.
>
>
>
> Sure, one could argue that favoring SACK over DSS is more important. But I
> think we would need data to justify that. Only very specific traffic
> patterns will fall in this use-case.
>
The bottomline is that in the event of a map being slightly delayed, i.e., delivered late with respect to the corresponding data, should it result in resetting the subflow?
As far as the specification is concerned, it could be liberal on accepting such maps, rather than being restrictive. Even if a current implementation cannot support this, future implementations may like to, provided the specification permits this and the implementation is willing to cop up with the associated complexity.
Best regards,
Anil
>
>
>
> Christoph
>
> >
> >
> >
> > With regards,
> >
> >
> >
> > Anil
> >
> >
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Christoph
> > >
> > >
> > > >
> > > >
> > > >
> > > > Further, segment-3 cannot combine/cover the data in segment-1 and segment-3 in a "single map", as the data sequence space is not continuous, i.e., some in between data (segment-2) is mapped and transmitted through subflow-2. Here, the map in segment-3 does not even partially cover the data it carries.
> > > >
> > > >
> > > >
> > > >
> > > > Both RFC 6824 and the 6824-bis do not restrict the above scenario, and I guess the change proposed now does not permit this to happen.
> > > >
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > >
> > > >
> > > >
> > > > Anil
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > That's the reason why we (the MPTCP-upstreaming community) vouch to have this case restricted.
> > > > >
> > > > >
> > > > >
> > > > > Cheers,
> > > > > Christoph
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Anil
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Best regards,
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
>
2 years, 6 months
[PATCH net-next v4 00/11]
by Mat Martineau
v3 -> v4: Update coalesce/collapse of incoming MPTCP skbs (patch 7)
v2 -> v3: Ensure sk_type alignment in struct sock (patch 2)
v1 -> v2: sk_pacing_shift left as a regular struct member (patch 2), and
modified SACK space check based on recent -net fix (patch 9).
The MPTCP upstreaming community has been collaborating on an
upstreamable MPTCP implementation that complies with RFC 8684. A minimal
set of features to comply with the specification involves a sizeable set
of code changes, so David requested that we split this work in to
multiple, smaller patch sets to build up MPTCP infrastructure.
The minimal MPTCP feature set we are proposing for review in the v5.6
timeframe begins with these three parts:
Part 1 (this patch set): MPTCP prerequisites. Introduce some MPTCP
definitions, additional ULP and skb extension features, TCP option space
checking, and a few exported symbols.
Part 2: Single subflow implementation and self tests.
Part 3: Switch from MPTCP v0 (RFC 6824) to MPTCP v1 (new RFC 8684,
publication expected in the next few days).
We plan to send those over the next week. Additional patches for
multiple subflow support, path management, active backup, and other
features are in the pipeline for submission after making progress with
the above reviews.
Clone/fetch:
https://github.com/multipath-tcp/mptcp_net-next.git (tag: netdev-v4-part1)
Browse:
https://github.com/multipath-tcp/mptcp_net-next/tree/netdev-v4-part1
Thank you for your review. You can find us at mptcp(a)lists.01.org and
https://is.gd/mptcp_upstream
Mat Martineau (9):
net: Make sock protocol value checks more specific
sock: Make sk_protocol a 16-bit value
tcp: Define IPPROTO_MPTCP
tcp: Add MPTCP option number
tcp, ulp: Add clone operation to tcp_ulp_ops
mptcp: Add MPTCP to skb extensions
tcp: coalesce/collapse must respect MPTCP extensions
tcp: Export TCP functions and ops struct
tcp: Check for filled TCP option space before SACK
Paolo Abeni (2):
tcp: clean ext on tx recycle
skb: add helpers to allocate ext independently from sk_buff
MAINTAINERS | 10 ++++
include/linux/skbuff.h | 6 +++
include/net/mptcp.h | 81 +++++++++++++++++++++++++++++++++
include/net/sock.h | 12 ++---
include/net/tcp.h | 22 +++++++++
include/trace/events/sock.h | 5 +-
include/uapi/linux/in.h | 2 +
net/ax25/af_ax25.c | 2 +-
net/core/skbuff.c | 42 ++++++++++++++++-
net/decnet/af_decnet.c | 2 +-
net/ipv4/inet_connection_sock.c | 2 +
net/ipv4/tcp.c | 6 +--
net/ipv4/tcp_input.c | 11 +++--
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/tcp_output.c | 12 +++--
net/ipv4/tcp_ulp.c | 12 +++++
net/ipv6/tcp_ipv6.c | 6 +--
tools/include/uapi/linux/in.h | 2 +
18 files changed, 211 insertions(+), 26 deletions(-)
create mode 100644 include/net/mptcp.h
--
2.24.1
2 years, 6 months
[PATCH v3] Squash-to: "tcp: Prevent coalesce/collapse when skb has MPTCP extensions"
by Paolo Abeni
Allow coalescing when mptcp extensions are equal or 'from' lacks such extensions.
Note: we could be a little less restrictive allowing coalescing with
different data_ack, but this simplify the code a bit, we can improve
later and at least mptcp_net-next do not generate almost identical
DSS with different data_ack.
With the above assumption, we don't need any special action when
moving bits from skb1 to skb2, as the mapping in skb2 will already
fit, and mapping in skb1 will be dropped as/if needed.
When coalescing to a newly allocated skb, we transfer the relevant
extension to. An MPTCP specific helper is added for that goal,
possibly we could use/create a generic one.
Rebased tree available at:
https://github.com/pabeni/mptcp/tree/mptcp_net-next_export_v4.3
v2 -> v3:
- refine mptcp_ext_matches() checks -> matches if !from_ext
(was from_ext == to_ext, which was more restrictive)
v1 -> v2:
- mptcp_skb_ext_move() is a no-op if from lack an MPTCP ext (Christoph)
- clean-up mptcp_skb_ext_move() as per Florian's suggestions
RFC -> v1:
- changed helpers checks as per Florian && Mat feedback
- added comments (Florian)
- fixed check in tcp_try_coalesce() (Mat)
- fixed memcpy (Mat && Florian)
- dropped now unused mptcp_skb_ext_exist()
- move the mptcp_skb_can_collapse() into the 2nd group of checks in
tcp_coalese()
This latter point is somewhat relevant. An unpatched kernel allows
collapsing a single skb with 'old' bits (seq lower than 'start'). Than
really means shrink a bit the current skb, possibly without any fourther
action. This change preserve this behavior, but add the restriction to
respect MPTCP coalescing test when trying to collapsing to the next one.
Overall consequences are not 110% clear to me!
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
include/net/mptcp.h | 46 ++++++++++++++++++++++++++++++++++++++++----
include/net/tcp.h | 2 +-
net/ipv4/tcp_input.c | 13 ++++++-------
3 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 43ddfdf9e4a3..8e27e33861ab 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -27,16 +27,54 @@ struct mptcp_ext {
#ifdef CONFIG_MPTCP
-static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
+/* move the skb extension owership, with the assumption that 'to' is
+ * newly allocated
+ */
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ struct sk_buff *from)
{
- return skb_ext_exist(skb, SKB_EXT_MPTCP);
+ if (!skb_ext_exist(from, SKB_EXT_MPTCP))
+ return;
+
+ if (WARN_ON_ONCE(to->active_extensions))
+ skb_ext_put(to);
+
+ to->active_extensions = from->active_extensions;
+ to->extensions = from->extensions;
+ from->active_extensions = 0;
+}
+
+static inline bool mptcp_ext_matches(const struct mptcp_ext *to_ext,
+ const struct mptcp_ext *from_ext)
+{
+ return !from_ext ||
+ (to_ext && from_ext &&
+ !memcmp(from_ext, to_ext, sizeof(struct mptcp_ext)));
+}
+
+/* check if skbs can be collapsed.
+ * MPTCP collapse is allowed if neither @to or @from carry an mptcp data
+ * mapping, or if the extension of @to is the same as @from.
+ * Collapsing is not possible if @to lacks an extension, but @from carries one.
+ */
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
+{
+ return mptcp_ext_matches(skb_ext_find(to, SKB_EXT_MPTCP),
+ skb_ext_find(from, SKB_EXT_MPTCP));
}
#else
-static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ const struct sk_buff *from)
+{
+}
+
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
{
- return false;
+ return true;
}
#endif /* CONFIG_MPTCP */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c483c73b8d41..f4cddd42d52a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -983,7 +983,7 @@ static inline bool tcp_skb_can_collapse(const struct sk_buff *to,
const struct sk_buff *from)
{
return likely(tcp_skb_can_collapse_to(to) &&
- !mptcp_skb_ext_exist(from));
+ mptcp_skb_can_collapse(to, from));
}
/* Events passed to congestion control interface */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 55b460a2ece2..a16d9f2a0529 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4420,7 +4420,7 @@ static bool tcp_try_coalesce(struct sock *sk,
if (TCP_SKB_CB(from)->seq != TCP_SKB_CB(to)->end_seq)
return false;
- if (mptcp_skb_ext_exist(from))
+ if (!mptcp_skb_can_collapse(to, from))
return false;
#ifdef CONFIG_TLS_DEVICE
@@ -4931,19 +4931,17 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
/* The first skb to collapse is:
* - not SYN/FIN and
- * - does not include a MPTCP skb extension
* - bloated or contains data before "start" or
- * overlaps to the next one.
+ * overlaps to the next one and mptcp allow collapsing.
*/
if (!(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) &&
- !mptcp_skb_ext_exist(skb) &&
(tcp_win_from_space(sk, skb->truesize) > skb->len ||
before(TCP_SKB_CB(skb)->seq, start))) {
end_of_skbs = false;
break;
}
- if (n && n != tail &&
+ if (n && n != tail && mptcp_skb_can_collapse(skb, n) &&
TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(n)->seq) {
end_of_skbs = false;
break;
@@ -4952,7 +4950,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
/* Decided to skip this, advance start seq. */
start = TCP_SKB_CB(skb)->end_seq;
}
- if (end_of_skbs || mptcp_skb_ext_exist(skb) ||
+ if (end_of_skbs ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
return;
@@ -4976,6 +4974,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
else
__skb_queue_tail(&tmp, nskb); /* defer rbtree insertion */
skb_set_owner_r(nskb, sk);
+ mptcp_skb_ext_move(nskb, skb);
/* Copy data, releasing collapsed skbs. */
while (copy > 0) {
@@ -4995,7 +4994,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
skb = tcp_collapse_one(sk, skb, list, root);
if (!skb ||
skb == tail ||
- mptcp_skb_ext_exist(skb) ||
+ !mptcp_skb_can_collapse(nskb, skb) ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
goto end;
#ifdef CONFIG_TLS_DEVICE
--
2.21.0
2 years, 6 months
[PATCH v2] Squash-to: "tcp: Prevent coalesce/collapse when skb has MPTCP extensions"
by Paolo Abeni
Allow coalescing when mptcp extensions are equal or 'from' lacks such extensions.
Note: we could be a little less restrictive allowing coalescing with
different data_ack, but this simplify the code a bit, we can improve
later and at least mptcp_net-next do not generate almost identical
DSS with different data_ack.
With the above assumption, we don't need any special action when
moving bits from skb1 to skb2, as the mapping in skb2 will already
fit, and mapping in skb1 will be dropped as/if needed.
When coalescing to a newly allocated skb, we transfer the relevant
extension to. An MPTCP specific helper is added for that goal,
possibly we could use/create a generic one.
Rebased tree available at:
https://github.com/pabeni/mptcp/tree/mptcp_net-next_export_v4.2
@Matt, can you please spin self-tests loop on top of this?
I'm running with KASAN build on v1 patches and on branch topmost
commit
v1 -> v2:
- mptcp_skb_ext_move() is a no-op if from lack an MPTCP ext (Christoph)
- clean-up mptcp_skb_ext_move() as per Florian's suggestions
RFC -> v1:
- changed helpers checks as per Florian && Mat feedback
- added comments (Florian)
- fixed check in tcp_try_coalesce() (Mat)
- fixed memcpy (Mat && Florian)
- dropped now unused mptcp_skb_ext_exist()
- move the mptcp_skb_can_collapse() into the 2nd group of checks in
tcp_coalese()
This latter point is somewhat relevant. An unpatched kernel allows
collapsing a single skb with 'old' bits (seq lower than 'start'). Than
really means shrink a bit the current skb, possibly without any fourther
action. This change preserve this behavior, but add the restriction to
respect MPTCP coalescing test when trying to collapsing to the next one.
Overall consequences are not 110% clear to me!
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
include/net/mptcp.h | 46 ++++++++++++++++++++++++++++++++++++++++----
include/net/tcp.h | 2 +-
net/ipv4/tcp_input.c | 13 ++++++-------
3 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 43ddfdf9e4a3..03240a6052e6 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -27,16 +27,54 @@ struct mptcp_ext {
#ifdef CONFIG_MPTCP
-static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
+/* move the skb extension owership, with the assumption that 'to' is
+ * newly allocated
+ */
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ struct sk_buff *from)
{
- return skb_ext_exist(skb, SKB_EXT_MPTCP);
+ if (!skb_ext_exist(from, SKB_EXT_MPTCP))
+ return;
+
+ if (WARN_ON_ONCE(to->active_extensions))
+ skb_ext_put(to);
+
+ to->active_extensions = from->active_extensions;
+ to->extensions = from->extensions;
+ from->active_extensions = 0;
+}
+
+static inline bool mptcp_ext_matches(const struct mptcp_ext *to_ext,
+ const struct mptcp_ext *from_ext)
+{
+ return to_ext == from_ext ||
+ (to_ext && from_ext &&
+ !memcmp(from_ext, to_ext, sizeof(struct mptcp_ext)));
+}
+
+/* check if skbs can be collapsed.
+ * MPTCP collapse is allowed if neither @to or @from carry an mptcp data
+ * mapping, or if the extension of @to is the same as @from.
+ * Collapsing is not possible if @to lacks an extension, but @from carries one.
+ */
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
+{
+ return mptcp_ext_matches(skb_ext_find(to, SKB_EXT_MPTCP),
+ skb_ext_find(from, SKB_EXT_MPTCP));
}
#else
-static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ const struct sk_buff *from)
+{
+}
+
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
{
- return false;
+ return true;
}
#endif /* CONFIG_MPTCP */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c483c73b8d41..f4cddd42d52a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -983,7 +983,7 @@ static inline bool tcp_skb_can_collapse(const struct sk_buff *to,
const struct sk_buff *from)
{
return likely(tcp_skb_can_collapse_to(to) &&
- !mptcp_skb_ext_exist(from));
+ mptcp_skb_can_collapse(to, from));
}
/* Events passed to congestion control interface */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 55b460a2ece2..a16d9f2a0529 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4420,7 +4420,7 @@ static bool tcp_try_coalesce(struct sock *sk,
if (TCP_SKB_CB(from)->seq != TCP_SKB_CB(to)->end_seq)
return false;
- if (mptcp_skb_ext_exist(from))
+ if (!mptcp_skb_can_collapse(to, from))
return false;
#ifdef CONFIG_TLS_DEVICE
@@ -4931,19 +4931,17 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
/* The first skb to collapse is:
* - not SYN/FIN and
- * - does not include a MPTCP skb extension
* - bloated or contains data before "start" or
- * overlaps to the next one.
+ * overlaps to the next one and mptcp allow collapsing.
*/
if (!(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) &&
- !mptcp_skb_ext_exist(skb) &&
(tcp_win_from_space(sk, skb->truesize) > skb->len ||
before(TCP_SKB_CB(skb)->seq, start))) {
end_of_skbs = false;
break;
}
- if (n && n != tail &&
+ if (n && n != tail && mptcp_skb_can_collapse(skb, n) &&
TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(n)->seq) {
end_of_skbs = false;
break;
@@ -4952,7 +4950,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
/* Decided to skip this, advance start seq. */
start = TCP_SKB_CB(skb)->end_seq;
}
- if (end_of_skbs || mptcp_skb_ext_exist(skb) ||
+ if (end_of_skbs ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
return;
@@ -4976,6 +4974,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
else
__skb_queue_tail(&tmp, nskb); /* defer rbtree insertion */
skb_set_owner_r(nskb, sk);
+ mptcp_skb_ext_move(nskb, skb);
/* Copy data, releasing collapsed skbs. */
while (copy > 0) {
@@ -4995,7 +4994,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
skb = tcp_collapse_one(sk, skb, list, root);
if (!skb ||
skb == tail ||
- mptcp_skb_ext_exist(skb) ||
+ !mptcp_skb_can_collapse(nskb, skb) ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
goto end;
#ifdef CONFIG_TLS_DEVICE
--
2.21.0
2 years, 6 months
[PATCH v1] Squash-to: "tcp: Prevent coalesce/collapse when skb has MPTCP extensions"
by Paolo Abeni
Allow coalescing when mptcp extensions are equal or 'from' lacks such extensions.
Note: we could be a little less restrictive allowing coalescing with
different data_ack, but this simplify the code a bit, we can improve
later and at least mptcp_net-next do not generate almost identical
DSS with different data_ack.
With the above assumption, we don't need any special action when
moving bits from skb1 to skb2, as the mapping in skb2 will already
fit, and mapping in skb1 will be dropped as/if needed.
When coalescing to a newly allocated skb, we transfer the relevant
extension to. An MPTCP specific helper is added for that goal,
possibly we could use/create a generic one.
RFC -> v1:
- changed helpers checks as per Florian && Mat feedback
- added comments (Florian)
- fixed check in tcp_try_coalesce() (Mat)
- fixed memcpy (Mat && Florian)
- dropped now unused mptcp_skb_ext_exist()
- move the mptcp_skb_can_collapse() into the 2nd group of checks in
tcp_coalese()
This latter point is somewhat relevant. An unpatched kernel allows
collapsing a single skb with 'old' bits (seq lower than 'start'). Than
really means shrink a bit the current skb, possibly without any fourther
action. This change preserve this behavior, but add the restriction to
respect MPTCP coalescing test when trying to collapsing to the next one.
Overall consequences are not 110% clear to me!
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
include/net/mptcp.h | 45 ++++++++++++++++++++++++++++++++++++++++----
include/net/tcp.h | 2 +-
net/ipv4/tcp_input.c | 13 ++++++-------
3 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 43ddfdf9e4a3..f0b8ee40fe5a 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -27,16 +27,53 @@ struct mptcp_ext {
#ifdef CONFIG_MPTCP
-static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
+/* move the skb extension owership, with the assumption that 'to' is
+ * newly allocated and 'from' carries only MPTCP ext
+ */
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ struct sk_buff *from)
+{
+ if (WARN_ON_ONCE(to->active_extensions))
+ skb_ext_put(to);
+ WARN_ON_ONCE(from->active_extensions & ~(1 << SKB_EXT_MPTCP));
+
+ to->active_extensions = from->active_extensions;
+ to->extensions = from->extensions;
+ from->extensions = NULL;
+ from->active_extensions = 0;
+}
+
+static inline bool mptcp_ext_matches(const struct mptcp_ext *to_ext,
+ const struct mptcp_ext *from_ext)
+{
+ return to_ext == from_ext ||
+ (to_ext && from_ext &&
+ !memcmp(from_ext, to_ext, sizeof(struct mptcp_ext)));
+}
+
+/* check if skbs can be collapsed.
+ * MPTCP collapse is allowed if neither @to or @from carry an mptcp data
+ * mapping, or if the extension of @to is the same as @from.
+ * Collapsing is not possible if @to lacks an extension, but @from carries one.
+ */
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
{
- return skb_ext_exist(skb, SKB_EXT_MPTCP);
+ return mptcp_ext_matches(skb_ext_find(to, SKB_EXT_MPTCP),
+ skb_ext_find(from, SKB_EXT_MPTCP));
}
#else
-static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ const struct sk_buff *from)
+{
+}
+
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
{
- return false;
+ return true;
}
#endif /* CONFIG_MPTCP */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c483c73b8d41..f4cddd42d52a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -983,7 +983,7 @@ static inline bool tcp_skb_can_collapse(const struct sk_buff *to,
const struct sk_buff *from)
{
return likely(tcp_skb_can_collapse_to(to) &&
- !mptcp_skb_ext_exist(from));
+ mptcp_skb_can_collapse(to, from));
}
/* Events passed to congestion control interface */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 55b460a2ece2..a16d9f2a0529 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4420,7 +4420,7 @@ static bool tcp_try_coalesce(struct sock *sk,
if (TCP_SKB_CB(from)->seq != TCP_SKB_CB(to)->end_seq)
return false;
- if (mptcp_skb_ext_exist(from))
+ if (!mptcp_skb_can_collapse(to, from))
return false;
#ifdef CONFIG_TLS_DEVICE
@@ -4931,19 +4931,17 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
/* The first skb to collapse is:
* - not SYN/FIN and
- * - does not include a MPTCP skb extension
* - bloated or contains data before "start" or
- * overlaps to the next one.
+ * overlaps to the next one and mptcp allow collapsing.
*/
if (!(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) &&
- !mptcp_skb_ext_exist(skb) &&
(tcp_win_from_space(sk, skb->truesize) > skb->len ||
before(TCP_SKB_CB(skb)->seq, start))) {
end_of_skbs = false;
break;
}
- if (n && n != tail &&
+ if (n && n != tail && mptcp_skb_can_collapse(skb, n) &&
TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(n)->seq) {
end_of_skbs = false;
break;
@@ -4952,7 +4950,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
/* Decided to skip this, advance start seq. */
start = TCP_SKB_CB(skb)->end_seq;
}
- if (end_of_skbs || mptcp_skb_ext_exist(skb) ||
+ if (end_of_skbs ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
return;
@@ -4976,6 +4974,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
else
__skb_queue_tail(&tmp, nskb); /* defer rbtree insertion */
skb_set_owner_r(nskb, sk);
+ mptcp_skb_ext_move(nskb, skb);
/* Copy data, releasing collapsed skbs. */
while (copy > 0) {
@@ -4995,7 +4994,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
skb = tcp_collapse_one(sk, skb, list, root);
if (!skb ||
skb == tail ||
- mptcp_skb_ext_exist(skb) ||
+ !mptcp_skb_can_collapse(nskb, skb) ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
goto end;
#ifdef CONFIG_TLS_DEVICE
--
2.21.0
2 years, 6 months
[RFC PATCH] Squash-to: "tcp: Prevent coalesce/collapse when skb has MPTCP extensions"
by Paolo Abeni
Allow coalescing when mptcp extensions are equal or 'from' lacks such extensions.
Note: we could be a little less restrictive allowing coalescing with
different data_ack, but this simplify the code a bit, we can improve
later and at least mptcp_net-next do not generate almost identical
DSS with different data_ack.
With the above assumption, we don't need any special action when
moving bits from skb1 to skb2, as the mapping in skb2 will already
fit, and mapping in skb1 will be dropped as/if needed.
When coalescing to a newly allocated skb, we transfer the relevant
extension to. An MPTCP specific helper is added for that goal,
possibly we could use/create a generic one.
Completely untested, just to collect early feedback.
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
include/net/mptcp.h | 38 ++++++++++++++++++++++++++++++++++++++
include/net/tcp.h | 2 +-
net/ipv4/tcp_input.c | 9 +++++----
3 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 43ddfdf9e4a3..8a702e7566e6 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -27,17 +27,55 @@ struct mptcp_ext {
#ifdef CONFIG_MPTCP
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ const struct sk_buff *from)
+{
+ skb_ext_put(to);
+
+ to->active_extensions = from->active_extensions;
+ to->extensions = from->extensions;
+ from->extensions = NULL;
+ from->active_extensions = 0;
+}
+
static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
{
return skb_ext_exist(skb, SKB_EXT_MPTCP);
}
+static inline bool mptcp_ext_matches(const struct mptcp_ext *to_ext,
+ const struct mptcp_ext *from_ext)
+{
+ return !memcmp(&from_ext->data_seq, &to_ext->data_seq);
+}
+
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
+{
+ const struct mptcp_ext *from_ext = skb_ext_find(from, SKB_EXT_MPTCP);
+ const struct mptcp_ext *to_ext = skb_ext_find(to, SKB_EXT_MPTCP);
+
+ return !from_ext || (to_ext && mptcp_ext_matches(to_ext, from_ext));
+}
+
#else
+static inline void mptcp_skb_ext_move(struct sk_buff *to,
+ const struct sk_buff *from)
+{
+}
+
static inline bool mptcp_skb_ext_exist(const struct sk_buff *skb)
{
return false;
}
+static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
+ const struct sk_buff *from)
+{
+ return true;
+}
+
+
#endif /* CONFIG_MPTCP */
#endif /* __NET_MPTCP_H */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c483c73b8d41..f4cddd42d52a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -983,7 +983,7 @@ static inline bool tcp_skb_can_collapse(const struct sk_buff *to,
const struct sk_buff *from)
{
return likely(tcp_skb_can_collapse_to(to) &&
- !mptcp_skb_ext_exist(from));
+ mptcp_skb_can_collapse(to, from));
}
/* Events passed to congestion control interface */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 55b460a2ece2..1c96c545a23a 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4420,7 +4420,7 @@ static bool tcp_try_coalesce(struct sock *sk,
if (TCP_SKB_CB(from)->seq != TCP_SKB_CB(to)->end_seq)
return false;
- if (mptcp_skb_ext_exist(from))
+ if (mptcp_skb_can_collapse(to, from))
return false;
#ifdef CONFIG_TLS_DEVICE
@@ -4931,12 +4931,12 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
/* The first skb to collapse is:
* - not SYN/FIN and
- * - does not include a MPTCP skb extension
+ * - MPTCP allow collapsing with the next one, if any
* - bloated or contains data before "start" or
* overlaps to the next one.
*/
if (!(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) &&
- !mptcp_skb_ext_exist(skb) &&
+ (!n || mptcp_skb_can_collapse(n, skb)) &&
(tcp_win_from_space(sk, skb->truesize) > skb->len ||
before(TCP_SKB_CB(skb)->seq, start))) {
end_of_skbs = false;
@@ -4976,6 +4976,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
else
__skb_queue_tail(&tmp, nskb); /* defer rbtree insertion */
skb_set_owner_r(nskb, sk);
+ mptcp_skb_ext_move(nskb, skb);
/* Copy data, releasing collapsed skbs. */
while (copy > 0) {
@@ -4995,7 +4996,7 @@ tcp_collapse(struct sock *sk, struct sk_buff_head *list, struct rb_root *root,
skb = tcp_collapse_one(sk, skb, list, root);
if (!skb ||
skb == tail ||
- mptcp_skb_ext_exist(skb) ||
+ !mptcp_skb_can_collapse(nskb, skb) ||
(TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
goto end;
#ifdef CONFIG_TLS_DEVICE
--
2.21.0
2 years, 6 months
[PATCH net-next v3 00/11] Multipath TCP: Prerequisites
by Mat Martineau
v2 -> v3: Ensure sk_type alignment in struct sock (patch 2)
v1 -> v2: sk_pacing_shift left as a regular struct member (patch 2), and
modified SACK space check based on recent -net fix (patch 9).
The MPTCP upstreaming community has been collaborating on an
upstreamable MPTCP implementation that complies with RFC 8684. A minimal
set of features to comply with the specification involves a sizeable set
of code changes, so David requested that we split this work in to
multiple, smaller patch sets to build up MPTCP infrastructure.
The minimal MPTCP feature set we are proposing for review in the v5.6
timeframe begins with these three parts:
Part 1 (this patch set): MPTCP prerequisites. Introduce some MPTCP
definitions, additional ULP and skb extension features, TCP option space
checking, and a few exported symbols.
Part 2: Single subflow implementation and self tests.
Part 3: Switch from MPTCP v0 (RFC 6824) to MPTCP v1 (new RFC 8684,
publication expected in the next few days).
We plan to send those over the next week. Additional patches for
multiple subflow support, path management, active backup, and other
features are in the pipeline for submission after making progress with
the above reviews.
Clone/fetch:
https://github.com/multipath-tcp/mptcp_net-next.git (tag: netdev-v3-part1)
Browse:
https://github.com/multipath-tcp/mptcp_net-next/tree/netdev-v3-part1
Thank you for your review. You can find us at mptcp(a)lists.01.org and
https://is.gd/mptcp_upstream
Mat Martineau (9):
net: Make sock protocol value checks more specific
sock: Make sk_protocol a 16-bit value
tcp: Define IPPROTO_MPTCP
tcp: Add MPTCP option number
tcp, ulp: Add clone operation to tcp_ulp_ops
mptcp: Add MPTCP to skb extensions
tcp: Prevent coalesce/collapse when skb has MPTCP extensions
tcp: Export TCP functions and ops struct
tcp: Check for filled TCP option space before SACK
Paolo Abeni (2):
tcp: clean ext on tx recycle
skb: add helpers to allocate ext independently from sk_buff
MAINTAINERS | 10 ++++++++
include/linux/skbuff.h | 6 +++++
include/net/mptcp.h | 43 +++++++++++++++++++++++++++++++++
include/net/sock.h | 12 ++++-----
include/net/tcp.h | 22 +++++++++++++++++
include/trace/events/sock.h | 5 ++--
include/uapi/linux/in.h | 2 ++
net/ax25/af_ax25.c | 2 +-
net/core/skbuff.c | 42 ++++++++++++++++++++++++++++++--
net/decnet/af_decnet.c | 2 +-
net/ipv4/inet_connection_sock.c | 2 ++
net/ipv4/tcp.c | 6 ++---
net/ipv4/tcp_input.c | 10 ++++++--
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/tcp_output.c | 12 ++++++---
net/ipv4/tcp_ulp.c | 12 +++++++++
net/ipv6/tcp_ipv6.c | 6 ++---
tools/include/uapi/linux/in.h | 2 ++
18 files changed, 173 insertions(+), 25 deletions(-)
create mode 100644 include/net/mptcp.h
--
2.24.1
2 years, 6 months
[PATCH] Squash-to: "mptcp: Add MPTCP socket stubs"
by Paolo Abeni
whoops, bad bitmask in previous commit - we must enumerate
the supported {recv,send}msg flags.
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
net/mptcp/protocol.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index cbd6c1e0fb96..5e24e7cf7d70 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -22,7 +22,7 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
struct mptcp_sock *msk = mptcp_sk(sk);
struct socket *subflow = msk->subflow;
- if (msg->msg_flags & ~(MSG_MORE | MSG_NOSIGNAL))
+ if (msg->msg_flags & ~(MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL))
return -EOPNOTSUPP;
return sock_sendmsg(subflow, msg);
@@ -34,7 +34,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
struct mptcp_sock *msk = mptcp_sk(sk);
struct socket *subflow = msk->subflow;
- if (msg->msg_flags & ~(MSG_MORE | MSG_PEEK))
+ if (msg->msg_flags & ~(MSG_WAITALL | MSG_DONTWAIT))
return -EOPNOTSUPP;
return sock_recvmsg(subflow, msg, flags);
--
2.21.0
2 years, 6 months
[PATCH 1/2] Squash-to: "mptcp: Add MPTCP socket stubs"
by Paolo Abeni
we will really support MSG_DONTWAIT in sendmsg()
and better set similar constraint on recvmsg() instead of
comments in later patch
---
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 2e0a3266725a..cbd6c1e0fb96 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -22,7 +22,7 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
struct mptcp_sock *msk = mptcp_sk(sk);
struct socket *subflow = msk->subflow;
- if (msg->msg_flags & ~(MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL))
+ if (msg->msg_flags & ~(MSG_MORE | MSG_NOSIGNAL))
return -EOPNOTSUPP;
return sock_sendmsg(subflow, msg);
@@ -34,6 +34,9 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
struct mptcp_sock *msk = mptcp_sk(sk);
struct socket *subflow = msk->subflow;
+ if (msg->msg_flags & ~(MSG_MORE | MSG_PEEK))
+ return -EOPNOTSUPP;
+
return sock_recvmsg(subflow, msg, flags);
}
--
2.21.0
2 years, 6 months