netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: netdev@vger.kernel.org, edumazet@google.com
Cc: Paolo Abeni <pabeni@redhat.com>,
	cpaasch@apple.com, fw@strlen.de, peter.krystad@linux.intel.com,
	dcaratti@redhat.com, matthieu.baerts@tessares.net
Subject: [RFC PATCH v3 10/10] tcp: clean ext on tx recycle
Date: Wed,  9 Oct 2019 16:08:09 -0700	[thread overview]
Message-ID: <20191009230809.27387-11-mathew.j.martineau@linux.intel.com> (raw)
In-Reply-To: <20191009230809.27387-1-mathew.j.martineau@linux.intel.com>

From: Paolo Abeni <pabeni@redhat.com>

Otherwise we will find stray/unexpected/old extensions
value on next iteration.

On tcp_write_xmit() we can end-up splitting an already queued
skb in two parts, via tso_fragment(). The newly created skb
can be allocated via the tx cache and the mptcp stack will not
be aware of it, so nobody set properly the MPTCP ext.

End result, we transmit the skb using an hold MPTCP DSS map
and that confuses the rx side/corrupt the stream. It requires
some concurrent conditions, so it's not deterministic.

Resetting the ext on recycle fixes all the current mptcp self tests
issues.

Apparently only MPTCP has issues with this kind of stray ext,
so an alternative would be add an additional mptcp hook in
tso_fragment() or in sk_stream_alloc_skb() to always init
the ext.

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
 include/net/sock.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/sock.h b/include/net/sock.h
index 4850c10461b8..84ea0efe7952 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1470,6 +1470,7 @@ static inline void sk_wmem_free_skb(struct sock *sk, struct sk_buff *skb)
 	sk_mem_uncharge(sk, skb->truesize);
 	if (static_branch_unlikely(&tcp_tx_skb_cache_key) &&
 	    !sk->sk_tx_skb_cache && !skb_cloned(skb)) {
+		skb_ext_reset(skb);
 		skb_zcopy_clear(skb, true);
 		sk->sk_tx_skb_cache = skb;
 		return;
-- 
2.23.0


      parent reply	other threads:[~2019-10-09 23:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 23:07 [RFC PATCH v3 00/10] Multipath TCP prerequisites Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 01/10] net: Make sock protocol value checks more specific Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 02/10] sock: Make sk_protocol a 16-bit value Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 03/10] tcp: Define IPPROTO_MPTCP Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 04/10] tcp: Add MPTCP option number Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 05/10] tcp, ulp: Add clone operation to tcp_ulp_ops Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 06/10] mptcp: Add MPTCP to skb extensions Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 07/10] tcp: Prevent coalesce/collapse when skb has MPTCP extensions Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 08/10] tcp: Export TCP functions and ops struct Mat Martineau
2019-10-09 23:08 ` [RFC PATCH v3 09/10] tcp: Check for filled TCP option space before SACK Mat Martineau
2019-10-09 23:08 ` Mat Martineau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191009230809.27387-11-mathew.j.martineau@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=cpaasch@apple.com \
    --cc=dcaratti@redhat.com \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=matthieu.baerts@tessares.net \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=peter.krystad@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).