From nobody Thu Sep 18 08:15:35 2025 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:ab0:35eb:0:0:0:0:0 with SMTP id w11csp1347338uau; Mon, 20 Jun 2022 04:26:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vqdXIUM/VDuz1rNlnMZosU3tUiQxbg+fWDnNeYPMfC4ZR3a9cQlBEqc1U0EBU5/d6b/W1Q X-Received: by 2002:a63:fb18:0:b0:408:b2c3:8dfd with SMTP id o24-20020a63fb18000000b00408b2c38dfdmr21101937pgh.448.1655724415225; Mon, 20 Jun 2022 04:26:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655724415; cv=none; d=google.com; s=arc-20160816; b=YH9lXJwshIVAfV+X7NaC/OVg4xaGYLCPMd/c834ooGnMf2bwz13PQvQBg9RNlb20fb d3TvLDlAMiFd1DfrzNVtfyyCMHRZh6LG39+Dko7FQKkhbt8cRjc84Zfso5Pfxo1WOjWy l/FTg3slUTjCccOjWFUrZQEl2jnIRxIuzpYfof5XPeqsnfEIsIyhDDdcuto3MX5BElCW hB3PbsFojhiicMlU8j91/DcPEKlIjxSHauva+kPUA8sBxvGMfA05gSGntG4VANpDDh6h EdXjMQg21ARVwOHzY3OdjJ/QFUkq1h/ChW33amFxgo7pZxXw2v5dQDA+cxASrUDtRD5H OWkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:to:from:dkim-signature; bh=Av8TpUGC4VOlwFitGVrmLJhb2bsuI5u1JkTtFTjnxjA=; b=DHOvGCjJW2N6I0Zo4yFd8jUKFkDKeY6N0Fm10JH1Iumim5hstgsBD1PxEZvq/RfiOW 40bFt7Kj/qJqB2znaWL63vra9NFYa0CrqL9aBu+SzXdUtY9/ODUInoqnGyXZ4gWSDdro 53cc1vNUVR3atKUfT30v/h1iLR6mPtfl8sYNKhw0mB3G8g+k1DOqXXXMX2pWuaR16vn1 HPSHlZ23CeHPgfIbwqAuoDNdJemNsE8mFpBKaGHL7XICP26BQmG4NMasDCkXkPNjkDJB T3zlnR3YjRTqW56XrBnWg7dB42eg2r3HwOw62a9da0lgFU2GwMo3lVNRfn1zqRo70Vxu lcmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="KuS/2D2u"; spf=pass (google.com: domain of mptcp+bounces-5710-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="mptcp+bounces-5710-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id m17-20020a170902db1100b001675b7b79d4si16525401plx.41.2022.06.20.04.26.55 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jun 2022 04:26:55 -0700 (PDT) Received-SPF: pass (google.com: domain of mptcp+bounces-5710-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="KuS/2D2u"; spf=pass (google.com: domain of mptcp+bounces-5710-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="mptcp+bounces-5710-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D88FA280BE6 for ; Mon, 20 Jun 2022 11:26:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5D326811; Mon, 20 Jun 2022 11:26:53 +0000 (UTC) X-Original-To: mptcp@lists.linux.dev 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 19AAD7F6 for ; Mon, 20 Jun 2022 11:26:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655724411; 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=Av8TpUGC4VOlwFitGVrmLJhb2bsuI5u1JkTtFTjnxjA=; b=KuS/2D2uOz7mEzco6nT0vm0abQLL8hOMmNeqt+BOdd5o5eSZfv5Nk13LkvfMmUqOp6YZT0 3WPrByOGbWjlcbBRAMvPJzadmLXUlJsj/cJjIHjgH5kT4Wspq6vfwQjSucNErSHqwoewni tQVbYwO5M0TDKqYuQ01mpZhvNKjONfI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-362-Oi2xkLiePuqKilrw02tzvA-1; Mon, 20 Jun 2022 07:26:49 -0400 X-MC-Unique: Oi2xkLiePuqKilrw02tzvA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 97BB2101AA45 for ; Mon, 20 Jun 2022 11:26:49 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.39.195.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id 27AA840BB4F for ; Mon, 20 Jun 2022 11:26:49 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH mptcp-net v4 5/6] mptcp: consistent map handling on failure Date: Mon, 20 Jun 2022 13:26:35 +0200 Message-Id: <1d9852cc1346d6cec5f18153d821aae69cb1840b.1655723410.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 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pabeni@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; x-default="true" When the MPTCP receive path reach a non fatal fall-back condition, e.g. when the MPC sockets must fall-back to TCP, the existing code is a little self-inconsistent: it reports that new data is available - return true - but sets the MPC flag to the opposite value. As the consequence read operations in some exceptional scenario may block unexpectedly. Address the issue setting the correct MPC read status. Additionally avoid some code duplication in the fatal fall-back scenario. Fixes: 9c81be0dbc89 ("mptcp: add MP_FAIL response support") Signed-off-by: Paolo Abeni --- net/mptcp/subflow.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 77fccc49d05c..5c87a269af80 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1252,17 +1252,12 @@ static bool subflow_check_data_avail(struct sock *s= sk) subflow->send_mp_fail =3D 1; =20 if (!READ_ONCE(msk->allow_infinite_fallback)) { - ssk->sk_err =3D EBADMSG; - tcp_set_state(ssk, TCP_CLOSE); subflow->reset_transient =3D 0; subflow->reset_reason =3D MPTCP_RST_EMIDDLEBOX; - tcp_send_active_reset(ssk, GFP_ATOMIC); - while ((skb =3D skb_peek(&ssk->sk_receive_queue))) - sk_eat_skb(ssk, skb); - } else { - mptcp_subflow_fail(msk, ssk); + goto reset; } - WRITE_ONCE(subflow->data_avail, MPTCP_SUBFLOW_NODATA); + mptcp_subflow_fail(msk, ssk); + WRITE_ONCE(subflow->data_avail, MPTCP_SUBFLOW_DATA_AVAIL); return true; } =20 @@ -1270,10 +1265,14 @@ static bool subflow_check_data_avail(struct sock *s= sk) /* fatal protocol error, close the socket. * subflow_error_report() will introduce the appropriate barriers */ - ssk->sk_err =3D EBADMSG; - tcp_set_state(ssk, TCP_CLOSE); subflow->reset_transient =3D 0; subflow->reset_reason =3D MPTCP_RST_EMPTCP; + +reset: + ssk->sk_err =3D EBADMSG; + tcp_set_state(ssk, TCP_CLOSE); + while ((skb =3D skb_peek(&ssk->sk_receive_queue))) + sk_eat_skb(ssk, skb); tcp_send_active_reset(ssk, GFP_ATOMIC); WRITE_ONCE(subflow->data_avail, MPTCP_SUBFLOW_NODATA); return false; --=20 2.35.3