From nobody Thu Nov 27 12:35:52 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9619311969 for ; Thu, 13 Nov 2025 23:07:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763075253; cv=none; b=OIupN8gQ82OvxZwAV6TyszAUUjVNQbkM4vygz6nrl+LwPI//rhonpjNluA4zdDc89fIQ5bhkMbqESiVOFZKvYlx/wohFHU1nB4WqjTOedePq6gun6W/el7ZBIYkorUYLfNp++maLZ0NsjZaMtyIlcY3MGYSRngEtorl4rSc9J1s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763075253; c=relaxed/simple; bh=q+zYn5n8j/3mZQxdzIAuybQEOOzeRTUwhTd+8uQjW/Y=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:content-type; b=kHdDaPxj5YkTYIKFHTb5mq7YY3r5ULwAPbxfVs2IgvP2pVBHNr2RiS6AAkRtLBltGsP6u2YN+UL8TRBN2TZwi4qj09MycsTt2/Dpl1U8gS0OvAd3KdKkMW78TqjmNIhJBT3+0DVdMMKE5GSjSZwG+4OZ+4Ihyaku/1pjX+4178o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=N5tUVwbX; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="N5tUVwbX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763075250; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=53YzFswBN0IuCTAWQlwgIEh2ElrEKCex7hvo/Dn3tbc=; b=N5tUVwbXPhmbvssJX41O5i4gY777JXozbtrogT7lKWR0U5uN8XePgi8VLD4tvJdV/58GuD ydwQN2qUKhiRhEJeKTFyEsUEquMqMOzgkg+vaUqlDgrYLUzWA8ADKvwYarBxF4VndD39zp tg2JCmNFM8nIJObx4bUNDi+V0SVV5cU= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-608-obhODuvVMGWQHHzanBQH9A-1; Thu, 13 Nov 2025 18:07:29 -0500 X-MC-Unique: obhODuvVMGWQHHzanBQH9A-1 X-Mimecast-MFC-AGG-ID: obhODuvVMGWQHHzanBQH9A_1763075248 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 720B4195609F for ; Thu, 13 Nov 2025 23:07:28 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.44.33.100]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 71F803000198 for ; Thu, 13 Nov 2025 23:07:27 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH mptcp-net 1/3] mptcp: fix premature close in case of fallback Date: Fri, 14 Nov 2025 00:05:29 +0100 Message-ID: <03e2e84a1b632063bc6ee47779b75b72b03227c7.1763075056.git.pabeni@redhat.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: TNNPwSZm-oMdg8MxmbZ7-F5-Dg-FIyVXQVAPXCXOLoU_1763075248 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; x-default="true" I'm observing very frequent self-tests failures in case of fallback when running on a CONFIG_PREEMPT kernel. The root cause is that subflow_sched_work_if_closed() closes any subflow as soon as it is half-closed and has no incoming data pending. That works well for regular subflows - MPTCP needs be-directional connectivity to operate on a given suflow - but for fallback socket is race prone. When TCP peer closes the connection before the MPTCP one, subflow_sched_work_if_closed() will schedule the MPTCP worker to gracefully close the subflow, and shortly after will do another schedule to inject and process a dummy incoming DATA_FIN. On CONFIG_PREEMPT kernel, the MPTCP worker can kick-in and close the fallback subflow before subflow_sched_work_if_closed() is able to create the dummy DATA_FIN, unexpectedly interrupting the transfer. Address the issue explicitly avoiding closing fallback subflows on when the peer is only half-closed. Note that, when the subflow is able to create the DATA_FIN before the worker invocation, the worker will change the msk state before trying to close the subflow and will skip the latter operation as the msk will not match anymore the precondition in __mptcp_close_subflow(). Fixes: f09b0ad55a11 ("mptcp: close subflow when receiving TCP+FIN") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) --- 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 935a32217741..1b222cd3096a 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2630,7 +2630,8 @@ static void __mptcp_close_subflow(struct sock *sk) =20 if (ssk_state !=3D TCP_CLOSE && (ssk_state !=3D TCP_CLOSE_WAIT || - inet_sk_state_load(sk) !=3D TCP_ESTABLISHED)) + inet_sk_state_load(sk) !=3D TCP_ESTABLISHED || + __mptcp_check_fallback(msk))) continue; =20 /* 'subflow_data_ready' will re-sched once rx queue is empty */ --=20 2.51.1 From nobody Thu Nov 27 12:35:52 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A02223F294 for ; Thu, 13 Nov 2025 23:07:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763075255; cv=none; b=lHo7KuyYbno239KMPyJNRY3KxstdxwZld/L0AHJGsgFOpB7IRXEKgdh/zBAWdWCNawfjhCKD2BzIIKEzj3r22ZcxBH0yO5FvZXM1PfOAg5kmIRHHSpnE2jdsFkhQjjg2IWIfksQO0gS8c2jplAl1LiFfsiEOnNTsy6KLgWdDyAQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763075255; c=relaxed/simple; bh=UQlu4ApwXTVrNVzd9dVUBYQChWw6FIihHGQ3j6/0apY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:content-type; b=QwffCbcKYKOoBzuMKN7J/JLsO6CchaRbCST0TV9cQEu1k5Sq5UX+nfI41gDHdMaX+xm6+xRo447Lg0N/F+VrhGRwW6rTKl0sXcBRfH5KiyvHXi6es/Hr29Lr26HN3Oef7nqY48SuJ6KI6Isa5WMSCt+zjN0yCH8R1sgrGe6KixU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=WHtdvuiN; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WHtdvuiN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763075253; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Oyi4yrMI3UI4WPwbG/khl0MiXAzQd6/mr3x80+9LXB4=; b=WHtdvuiNGHSCtEQWjp3fripXQ7xXbCpCmvBOQOgyFDNO5ZjYH/tkHzguPOFGhC3tzJNhfe XCl/jKkiIXwunjFVjBLnhznGVNWsQ1w9fA06uT53o3QRBAQVxlpXlcOa8gKrmb1+OBpdqj YR6UozlqCazZgLOa/DFd2X+UyF/WVHo= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-279-0N-sMuIJPxGH932pk-fjNg-1; Thu, 13 Nov 2025 18:07:31 -0500 X-MC-Unique: 0N-sMuIJPxGH932pk-fjNg-1 X-Mimecast-MFC-AGG-ID: 0N-sMuIJPxGH932pk-fjNg_1763075250 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8F9BF1956096 for ; Thu, 13 Nov 2025 23:07:30 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.44.33.100]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0EE73300018D for ; Thu, 13 Nov 2025 23:07:28 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH mptcp-net 2/3] mptcp: do not fallback when OoO is present Date: Fri, 14 Nov 2025 00:05:30 +0100 Message-ID: <1ec1d02676bf90ef3aaca85bf5b0cccc81556548.1763075056.git.pabeni@redhat.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ZTX0Etw51ZImt1ToPlpjMQ-MNPC9v9FWqxXkUVqjreQ_1763075250 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; x-default="true" In case of DSS corruption, the MPTCP protocol tries to avoid the subflow reset if fallback is possible. Such corruptions happen in the receive path; to ensure fallback is possible the stack additionally need to check for OoO data, otherwise the fallback will break the data stream. Fixes: e32d262c89e2 ("mptcp: handle consistently DSS corruption") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/598 Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) --- Note: this does not avoid the WARN(), but fixes the inconsistend read() behavior; the ingress data is OoO, we should not ack it --- net/mptcp/protocol.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 1b222cd3096a..f5761bff288c 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -78,6 +78,13 @@ bool __mptcp_try_fallback(struct mptcp_sock *msk, int fb= _mib) if (__mptcp_check_fallback(msk)) return true; =20 + /* The caller possibly is not holding the msk socket lock, but + * in the fallback case only the current subflow is touching + * the OoO queue. + */ + if (!RB_EMPTY_ROOT(&msk->out_of_order_queue)) + return false; + spin_lock_bh(&msk->fallback_lock); if (!msk->allow_infinite_fallback) { spin_unlock_bh(&msk->fallback_lock); --=20 2.51.1 From nobody Thu Nov 27 12:35:52 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D559D23F294 for ; Thu, 13 Nov 2025 23:07:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763075261; cv=none; b=CcNeObaB5RskSnumlpN6FgoEMRa9iLXu4pVYtdU3EzlzsWIk22FdivPhjKhg/C9r4YncBLADgpJmFf2+4oxmhyxFR8T5Qrv2z7rA+LYR2ewuRw5TgawMATU+CSbSS4ncZA6ofUta5pPQPcC1MrDLDCZxfe7TrxlA1K8YWk0Hbls= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763075261; c=relaxed/simple; bh=GynJi2mTkwYogh0URQ0zMi7Vg6g3Msh+JcDpa95ZU14=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:content-type; b=FkexcYWFwP9nPBGbcKyOQUIbU32Z9AY1trliNJPV7bCZH7NFLiBlz//w3FbxlCE0AGza4eAHxlnkeDXPc3MztR2KjBr5czeMFDT8gcKk2Yyn2Z0KqCUPIcMpbGHTvweUY2WGyjk/XXs/h4ZjhUnwps6IuzH2j9lZr02uRZzGmlk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TQZX0Q2X; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TQZX0Q2X" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763075258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I3uQGdHbuCbghLxW9LzLdFhFvV+YY5c43LPbc3tcdik=; b=TQZX0Q2XplNfczynw+xbEAuRW3O8fsOReHRDeRJhicCPrSvNpM0WUhUzcoTbafFSRO8+DW FmVFc9L82yp5fAucL9T9OYm+WGLtXFIFu+LJiJaXCLyZ1VUsqcuDdNAQKKNNoxZQGVpGDy lc93vWcGEaokWBfhUPddEti9IBlnvG0= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-209-VjeTsUQ7NU6WQrgMG2Te-g-1; Thu, 13 Nov 2025 18:07:34 -0500 X-MC-Unique: VjeTsUQ7NU6WQrgMG2Te-g-1 X-Mimecast-MFC-AGG-ID: VjeTsUQ7NU6WQrgMG2Te-g_1763075253 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3DDB21956089 for ; Thu, 13 Nov 2025 23:07:33 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.44.33.100]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id AC072300018D for ; Thu, 13 Nov 2025 23:07:30 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH mptcp-net 3/3] mptcp: do not drop partial packets. Date: Fri, 14 Nov 2025 00:05:31 +0100 Message-ID: In-Reply-To: References: Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EkcsJQgxuP3udEuWG5JRlf5SMFFWaR1c49NU_Mfy9u8_1763075253 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; x-default="true" Currently MPTCP drops partial packets for no good reason at all. Instead we should just skip the already acked bytes. Also add a missing check for zero window, which in turn requires properly initializing the rcv_wnd_sent at connection creation time. Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) --- Notes: - We should also add a MIB for zerowin drop, but that should be a follow-up patch, I think. - based on top of 'mptcp: autotune related improvement', but targeting net, will have a conflict in __mptcp_move_skb(). --- net/mptcp/protocol.c | 27 ++++++++++++++++++++------- net/mptcp/subflow.c | 3 ++- 2 files changed, 22 insertions(+), 8 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index f5761bff288c..78ac8ba80e59 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -385,6 +385,10 @@ static bool __mptcp_move_skb(struct sock *sk, struct s= k_buff *skb) =20 mptcp_borrow_fwdmem(sk, skb); =20 + /* Check for zero window.*/ + if (atomic64_read(&msk->rcv_wnd_sent) =3D=3D msk->ack_seq) + goto drop; + if (MPTCP_SKB_CB(skb)->map_seq =3D=3D msk->ack_seq) { /* in sequence */ msk->bytes_received +=3D copy_len; @@ -393,18 +397,27 @@ static bool __mptcp_move_skb(struct sock *sk, struct = sk_buff *skb) if (tail && mptcp_try_coalesce(sk, tail, skb)) return true; =20 - skb_set_owner_r(skb, sk); - __skb_queue_tail(&sk->sk_receive_queue, skb); - return true; + goto enqueue; } else if (after64(MPTCP_SKB_CB(skb)->map_seq, msk->ack_seq)) { mptcp_data_queue_ofo(msk, skb); return false; } =20 - /* old data, keep it simple and drop the whole pkt, sender - * will retransmit as needed, if needed. - */ - MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA); + /* Check for old data. */ + if (!after64(MPTCP_SKB_CB(skb)->end_seq, msk->ack_seq)) { + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA); + goto drop; + } + + /* Partial packet, seq < rcv_next < end_seq. */ + MPTCP_SKB_CB(skb)->offset +=3D msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq; + +enqueue: + skb_set_owner_r(skb, sk); + __skb_queue_tail(&sk->sk_receive_queue, skb); + return true; + +drop: mptcp_drop(sk, skb); return false; } diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 86ce58ae533d..43a2ff058ba5 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -497,7 +497,8 @@ static void subflow_set_remote_key(struct mptcp_sock *m= sk, WRITE_ONCE(msk->remote_key, subflow->remote_key); WRITE_ONCE(msk->ack_seq, subflow->iasn); WRITE_ONCE(msk->can_ack, true); - atomic64_set(&msk->rcv_wnd_sent, subflow->iasn); + atomic64_set(&msk->rcv_wnd_sent, subflow->iasn + + tcp_receive_window(tcp_sk(subflow->tcp_sock))); } =20 static void mptcp_propagate_state(struct sock *sk, struct sock *ssk, --=20 2.51.1