From patchwork Wed Dec 16 11:48:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 11977329 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F619C0018C for ; Wed, 16 Dec 2020 11:50:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B7CB3233EA for ; Wed, 16 Dec 2020 11:50:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725868AbgLPLuX (ORCPT ); Wed, 16 Dec 2020 06:50:23 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:40909 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725806AbgLPLuX (ORCPT ); Wed, 16 Dec 2020 06:50:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608119337; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MJotpa5UrA2ZqCRh7mc8/o/xpESWufExRhTpzsjWsRE=; b=aEiKcYJUgkrsoA24oeOA5eohShJ2nrnH/F0VuKWyUO3OQpb2sluwEpnxw187VRpHYE68g2 A6x1OelY6VlXOFi1Y/v+9EIQow0zs+hgrCXypuiKr7tdQDuR3GQB/MGQoYonhfifTFhq2F RDyLxUxJjnJEG9KxMjkC3LhyEepCieU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-586-RQqi7QP1PSeX4dlz87-RIw-1; Wed, 16 Dec 2020 06:48:55 -0500 X-MC-Unique: RQqi7QP1PSeX4dlz87-RIw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BFBAF9CDBA; Wed, 16 Dec 2020 11:48:50 +0000 (UTC) Received: from gerbillo.redhat.com (ovpn-112-143.ams2.redhat.com [10.36.112.143]) by smtp.corp.redhat.com (Postfix) with ESMTP id 051A077F3F; Wed, 16 Dec 2020 11:48:48 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Jakub Kicinski , mptcp@lists.01.org Subject: [PATCH net 1/4] mptcp: fix security context on server socket Date: Wed, 16 Dec 2020 12:48:32 +0100 Message-Id: <1bf3ee9b0c79a1e619fe4749d926aab71f0a7bcc.1608114076.git.pabeni@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org Currently MPTCP is not propagating the security context from the ingress request socket to newly created msk at clone time. Address the issue invoking the missing security helper. Fixes: cf7da0d66cc1 ("mptcp: Create SUBFLOW socket for incoming connections") Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau --- net/mptcp/protocol.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index b812aaae8044..d24243a28fce 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2699,6 +2699,8 @@ struct sock *mptcp_sk_clone(const struct sock *sk, sock_reset_flag(nsk, SOCK_RCU_FREE); /* will be fully established after successful MPC subflow creation */ inet_sk_state_store(nsk, TCP_SYN_RECV); + + security_inet_csk_clone(nsk, req); bh_unlock_sock(nsk); /* keep a single reference */ From patchwork Wed Dec 16 11:48:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 11977337 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A388EC2BBD5 for ; Wed, 16 Dec 2020 11:50:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6CB3F233A0 for ; Wed, 16 Dec 2020 11:50:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725968AbgLPLu2 (ORCPT ); Wed, 16 Dec 2020 06:50:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:49426 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725871AbgLPLu0 (ORCPT ); Wed, 16 Dec 2020 06:50:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608119340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ANHThWdmFFxL8/YxR3ZIed/xwyinScbXYPrqp44Ii0c=; b=ZhS0xHM7AJd1dVmGmSxo9IUna5FbRzoMTb/GNTvZvEjxL6GuVviaJ6+0GDRov8RUFRSs5z YfdhCVg/+Ry9rnHpVDs5x2CRKOIohMKIz1xidm8szeeDn4ivWROhvlvNOOSlKaACiWeJc0 duHHzYUkKJ3vj68z/+XRUlbmvIGSmmE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-480-1WnE-JDvO-Kl0-pA87_C2Q-1; Wed, 16 Dec 2020 06:48:58 -0500 X-MC-Unique: 1WnE-JDvO-Kl0-pA87_C2Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D2CEF800479; Wed, 16 Dec 2020 11:48:51 +0000 (UTC) Received: from gerbillo.redhat.com (ovpn-112-143.ams2.redhat.com [10.36.112.143]) by smtp.corp.redhat.com (Postfix) with ESMTP id A619B77F12; Wed, 16 Dec 2020 11:48:50 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Jakub Kicinski , mptcp@lists.01.org Subject: [PATCH net 2/4] mptcp: properly annotate nested lock Date: Wed, 16 Dec 2020 12:48:33 +0100 Message-Id: <0cbf6359084bee1187ba382a015d8809e2ce2416.1608114076.git.pabeni@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org MPTCP closes the subflows while holding the msk-level lock. While acquiring the subflow socket lock we need to use the correct nested annotation, or we can hit a lockdep splat at runtime. Reported-and-tested-by: Geliang Tang Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close") Signed-off-by: Paolo Abeni Reviewed-by: Mat Martineau --- net/mptcp/protocol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index d24243a28fce..64c0c54c80e8 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2119,7 +2119,7 @@ void __mptcp_close_ssk(struct sock *sk, struct sock *ssk, list_del(&subflow->node); - lock_sock(ssk); + lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); /* if we are invoked by the msk cleanup code, the subflow is * already orphaned From patchwork Wed Dec 16 11:48:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 11977333 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4564BC2BBD4 for ; Wed, 16 Dec 2020 11:50:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 166C8233A0 for ; Wed, 16 Dec 2020 11:50:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725966AbgLPLu0 (ORCPT ); Wed, 16 Dec 2020 06:50:26 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:39449 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725806AbgLPLuZ (ORCPT ); Wed, 16 Dec 2020 06:50:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608119338; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oZymnfnkQoDkdLEP/PpajDTJn5dj9lcyFPXOS9Y0740=; b=CY/+hNZkKUaCxq59rMix4easoUXnIO3CAB/Fnxl/FLAa2ZETwARa9YjPbDbH+EmsKImM0/ m0fWgv9iGtqIm0dssrp8B2OvOmnP1VV77qwKnCJbTX/8TiLn7QaLFjoia1qv71i/zxNJM+ 54Yy4uIDYeVlklZ8O0dA5MQ14MwrKi4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-275-AAIfeIRSNxGvQ43_9tDqIA-1; Wed, 16 Dec 2020 06:48:56 -0500 X-MC-Unique: AAIfeIRSNxGvQ43_9tDqIA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7A869102CB67; Wed, 16 Dec 2020 11:48:53 +0000 (UTC) Received: from gerbillo.redhat.com (ovpn-112-143.ams2.redhat.com [10.36.112.143]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3810060CC3; Wed, 16 Dec 2020 11:48:52 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Jakub Kicinski , mptcp@lists.01.org Subject: [PATCH net 3/4] mptcp: push pending frames when subflow has free space Date: Wed, 16 Dec 2020 12:48:34 +0100 Message-Id: <96d38017eb3b407449776e9ae788a4418496e55e.1608114076.git.pabeni@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org When multiple subflows are active, we can receive a window update on subflow with no write space available. MPTCP will try to push frames on such subflow and will fail. Pending frames will be pushed only after receiving a window update on a subflow with some wspace available. Overall the above could lead to suboptimal aggregate bandwidth usage. Instead, we should try to push pending frames as soon as the subflow reaches both conditions mentioned above. We can finally enable self-tests with asymmetric links, as the above makes them finally pass. Fixes: 6f8a612a33e4 ("mptcp: keep track of advertised windows right edge") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni --- net/mptcp/options.c | 13 ++++++++----- net/mptcp/protocol.c | 2 +- net/mptcp/protocol.h | 2 +- tools/testing/selftests/net/mptcp/simult_flows.sh | 6 +++--- 4 files changed, 13 insertions(+), 10 deletions(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index c5328f407aab..1fbd305ebd92 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -873,10 +873,13 @@ static void ack_update_msk(struct mptcp_sock *msk, new_wnd_end = new_snd_una + tcp_sk(ssk)->snd_wnd; - if (after64(new_wnd_end, msk->wnd_end)) { + if (after64(new_wnd_end, msk->wnd_end)) msk->wnd_end = new_wnd_end; - __mptcp_wnd_updated(sk, ssk); - } + + /* this assumes mptcp_incoming_options() is invoked after tcp_ack() */ + if (after64(msk->wnd_end, READ_ONCE(msk->snd_nxt)) && + sk_stream_memory_free(ssk)) + __mptcp_check_push(sk, ssk); if (after64(new_snd_una, old_snd_una)) { msk->snd_una = new_snd_una; @@ -942,8 +945,8 @@ void mptcp_incoming_options(struct sock *sk, struct sk_buff *skb) * helpers are cheap. */ mptcp_data_lock(subflow->conn); - if (mptcp_send_head(subflow->conn)) - __mptcp_wnd_updated(subflow->conn, sk); + if (sk_stream_memory_free(sk)) + __mptcp_check_push(subflow->conn, sk); __mptcp_data_acked(subflow->conn); mptcp_data_unlock(subflow->conn); return; diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 64c0c54c80e8..b53a91801a6c 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2915,7 +2915,7 @@ void __mptcp_data_acked(struct sock *sk) mptcp_schedule_work(sk); } -void __mptcp_wnd_updated(struct sock *sk, struct sock *ssk) +void __mptcp_check_push(struct sock *sk, struct sock *ssk) { if (!mptcp_send_head(sk)) return; diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 7cf9d110b85f..d67de793d363 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -503,7 +503,7 @@ void mptcp_rcv_space_init(struct mptcp_sock *msk, const struct sock *ssk); void mptcp_data_ready(struct sock *sk, struct sock *ssk); bool mptcp_finish_join(struct sock *sk); bool mptcp_schedule_work(struct sock *sk); -void __mptcp_wnd_updated(struct sock *sk, struct sock *ssk); +void __mptcp_check_push(struct sock *sk, struct sock *ssk); void __mptcp_data_acked(struct sock *sk); void mptcp_subflow_eof(struct sock *sk); bool mptcp_update_rcv_data_fin(struct mptcp_sock *msk, u64 data_fin_seq, bool use_64bit); diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/testing/selftests/net/mptcp/simult_flows.sh index 2f649b431456..f039ee57eb3c 100755 --- a/tools/testing/selftests/net/mptcp/simult_flows.sh +++ b/tools/testing/selftests/net/mptcp/simult_flows.sh @@ -287,7 +287,7 @@ run_test 10 10 0 0 "balanced bwidth" run_test 10 10 1 50 "balanced bwidth with unbalanced delay" # we still need some additional infrastructure to pass the following test-cases -# run_test 30 10 0 0 "unbalanced bwidth" -# run_test 30 10 1 50 "unbalanced bwidth with unbalanced delay" -# run_test 30 10 50 1 "unbalanced bwidth with opposed, unbalanced delay" +run_test 30 10 0 0 "unbalanced bwidth" +run_test 30 10 1 50 "unbalanced bwidth with unbalanced delay" +run_test 30 10 50 1 "unbalanced bwidth with opposed, unbalanced delay" exit $ret From patchwork Wed Dec 16 11:48:35 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Abeni X-Patchwork-Id: 11977335 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79139C2BBCF for ; Wed, 16 Dec 2020 11:50:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3FF432339F for ; Wed, 16 Dec 2020 11:50:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725970AbgLPLu2 (ORCPT ); Wed, 16 Dec 2020 06:50:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:58919 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725806AbgLPLu2 (ORCPT ); Wed, 16 Dec 2020 06:50:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608119341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mJOqHmUb8CNA4bRlVwBmxwsPIeaQxlh4BRVnFNKIsy0=; b=iJ0oM/o40FubwTA4kHyhTyF4fGVvV7HXCTgFULm8LlomFqMVRULSI8ZDA32VFLPj7HwXad JG9QH6Edd6hHEihMtSwQxIHI956r/F31DQ9FvYgAV5PS2TB0lKjdJIfCs0kL6pF3EpS3dG psJs2ezHpUpog//nnwhO8QbZXUIxlBw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-211-iH3yOxgbMy2pDK2BHK3BJw-1; Wed, 16 Dec 2020 06:49:00 -0500 X-MC-Unique: iH3yOxgbMy2pDK2BHK3BJw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ECA07B812C; Wed, 16 Dec 2020 11:48:54 +0000 (UTC) Received: from gerbillo.redhat.com (ovpn-112-143.ams2.redhat.com [10.36.112.143]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB51F60843; Wed, 16 Dec 2020 11:48:53 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: "David S. Miller" , Jakub Kicinski , mptcp@lists.01.org Subject: [PATCH net 4/4] mptcp: fix pending data accounting Date: Wed, 16 Dec 2020 12:48:35 +0100 Message-Id: <500ca762741cdb005751703f89ffa374c338ae7b.1608114076.git.pabeni@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org When sendmsg() needs to wait for memory, the pending data is not updated. That causes a drift in forward memory allocation, leading to stall and/or warnings at socket close time. This change addresses the above issue moving the pending data counter update inside the sendmsg() main loop. Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni --- net/mptcp/protocol.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index b53a91801a6c..09b19aa2f205 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -1658,6 +1658,7 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) frag_truesize += psize; pfrag->offset += frag_truesize; WRITE_ONCE(msk->write_seq, msk->write_seq + psize); + msk->tx_pending_data += psize; /* charge data on mptcp pending queue to the msk socket * Note: we charge such data both to sk and ssk @@ -1683,10 +1684,8 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) goto out; } - if (copied) { - msk->tx_pending_data += copied; + if (copied) mptcp_push_pending(sk, msg->msg_flags); - } out: release_sock(sk);