From nobody Thu Sep 18 08:17:43 2025 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:a9f:3042:0:0:0:0:0 with SMTP id i2csp209412uab; Wed, 15 Jun 2022 13:28:33 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v0mkGCEAHZRiIfzwDJAfAgAHfAHuzL0DamIdIBVNGWN9wkkRdsPAIKrkkZzFBE6eWmSaAI X-Received: by 2002:a05:6830:1e91:b0:60c:29fa:9fa0 with SMTP id n17-20020a0568301e9100b0060c29fa9fa0mr731173otr.23.1655324912925; Wed, 15 Jun 2022 13:28:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655324912; cv=none; d=google.com; s=arc-20160816; b=nPGjfGwk+qtX23K5FZFBGArKSu7ljVKxfObg74kbNI7yqRXJ/X+mjVHPhu0ySi7/D/ L/WAi5cT75Y+nnp/mnseLKbvQeELgsR6gr8n+ZAsRuF4ZAQFB3vWnuHVSS/IBRQM3UdT nJ/fWdpnGgKzz0/mLbx7+zI13m5wWP6OpC31zCl8PrWvz5BQHC089EockD1ybSjiF0mp t7BW4vxyTU8gr/LnOLn73A3647MMk9jpnraCIGQtTmyNW9vqVbVtsieJiLw1I72w3AyF 4RUYG7so8f8tw1kp4b05Npv7A7kW3zyqAx+Ilt4f37o1vkTrKjkA6Qr8Y3RnpjP/0Xwy EUFA== 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=tJS/33G/jdeIT0WGkXjxwdl7IgG+gCx7SWlT7UoUkzE=; b=0bqLlMAuYnwSZGn4DnKnFiVNVG+qJIcN9ZDH330QpomBZUkXxNuMwnkj+11+R1GIoS 3ZdGQGQ9eaB7Xr/MEhvFEDfEe3zUN1o7XJRk8AxD7GowsV94xXTPqcEdjaWLv3TymfYw LP2pg8uLOfFBtYcewoVjYzLGS8n2rf5OZKIZjrwxvTg5ahoP11ipdAQCEPSqFWeuK/BD Tplssu6xrKu1j3GsG3fGkdJxF5fltz8J0z4hISkbtNURAdRmP37Duml6HTCfHQa4ZCDB icLUWXLNS6lKSWAT4cHHHLoh4gMBB6ECWOuFwjOz9rxeuK4sfguohynhBRFs5qHIfKz3 BUcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Rqq3NXCg; spf=pass (google.com: domain of mptcp+bounces-5664-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.84.19 as permitted sender) smtp.mailfrom="mptcp+bounces-5664-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from da.mirrors.kernel.org (da.mirrors.kernel.org. [139.178.84.19]) by mx.google.com with ESMTPS id w24-20020a4ae9f8000000b0041b87ed09bfsi187702ooc.22.2022.06.15.13.28.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jun 2022 13:28:32 -0700 (PDT) Received-SPF: pass (google.com: domain of mptcp+bounces-5664-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.84.19 as permitted sender) client-ip=139.178.84.19; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Rqq3NXCg; spf=pass (google.com: domain of mptcp+bounces-5664-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.84.19 as permitted sender) smtp.mailfrom="mptcp+bounces-5664-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 da.mirrors.kernel.org (Postfix) with ESMTPS id C00CE2E0A24 for ; Wed, 15 Jun 2022 20:28:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BB4F93D9A; Wed, 15 Jun 2022 20:28:28 +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 6B7F03D9D for ; Wed, 15 Jun 2022 20:28:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655324906; 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=tJS/33G/jdeIT0WGkXjxwdl7IgG+gCx7SWlT7UoUkzE=; b=Rqq3NXCgzBezbgndYu4VJCw17xctZeEF9W16elCfth/2I8wgs/FEtegbB1NpP4UdRCbjUt s+FeM+uToPRoWV+Xfx0rjqspHT6+Bxt6tZvjp9m+naeNDks1uPmgymDqzhuNktu3uQL1NF Vh2VUD3vRJodqU1ipsNYDbHmXzJMENI= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-488-py7qMqxaOzKMwtLc8cfr6g-1; Wed, 15 Jun 2022 16:28:25 -0400 X-MC-Unique: py7qMqxaOzKMwtLc8cfr6g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0B10F299E77E for ; Wed, 15 Jun 2022 20:28:25 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.39.193.220]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8DFA040C1288 for ; Wed, 15 Jun 2022 20:28:24 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH mptcp-net v2 5/6] mptcp: consistent map handling on failure Date: Wed, 15 Jun 2022 22:28:12 +0200 Message-Id: <7aa8059e8fbbeab845269969ad02784a8c53fb1b.1655324843.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.84 on 10.11.54.2 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 75fdc6474d0e..bec36e2bcc32 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1246,17 +1246,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 @@ -1264,10 +1259,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