From nobody Mon Feb 9 01:49:07 2026 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:ab0:35eb:0:0:0:0:0 with SMTP id w11csp2037015uau; Tue, 21 Jun 2022 10:23:44 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sSSqhdlWdRXxiGCHgVRSjVmetu0+4w/wHT28DS9FqSBmSV5Z7gkefwPPHxriU8EHlVQr0L X-Received: by 2002:a63:4c1d:0:b0:3fd:9833:cdd9 with SMTP id z29-20020a634c1d000000b003fd9833cdd9mr27638014pga.103.1655832224670; Tue, 21 Jun 2022 10:23:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655832224; cv=none; d=google.com; s=arc-20160816; b=JK7p/zFsewGKReipMKhVqWIAodknkDWxEL6XtdkF/N2Dymn2WreOcsiDWjiTlMFKH3 aH6LcIW+IytLJRH6YlnkdT+RxVO+wrjbNBe01NVDrlNZLSMdV7JdgoFBTa49tudw61po pzp4SjHvyhWh00RUoD92ZusedOXQ4PADpqx1ri3mz5nRYGom0hxQu1sjS+cWxjF9hool paRamMWP8nTSLZjBxLqng04XkxrK4H+/JCeEGEJzbVP9d6kZATvSgBKekPJPjdV29xgG gIO7X/xqDBqijfGEtWpNb7fzAt8/TKZ6NS3g2+BCzd//0B2JwXej6n2pIxiAdmRXgfOw uQKA== 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=Jlv6VxF2I+Cgnh+o/o5MiT2WPEXqXllggOw4nKVeXSZdciCn4WtINCkyF4yc/W+hyC TjIyWvZzZG6MD2vG97dU91x8i6pQMK7BrvM9S+n6lrBE1AnNhS/JaDUp6iD6YNnrSKVB TWeEPwj00cXAphQSxVVipWsZGaMKM/CXt/CHX0uwOzwqJ6yr7zjNkvFMWosUC98zm91A vDYfYs9UOwBV+FI2dxcmHNtTseFaMkwxEmyNZ6uFz6Whb2F0QWIiqLswMpKBCt5SJl/f quD9QVVu28dJbpNBKoBxea5XH9hBnS9a7mjQEU2Jpg6jSAkgwcUk+xJLRlP/spbzSpUB MKkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ilajmhys; spf=pass (google.com: domain of mptcp+bounces-5745-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.88.99 as permitted sender) smtp.mailfrom="mptcp+bounces-5745-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. [139.178.88.99]) by mx.google.com with ESMTPS id np16-20020a17090b4c5000b001eccb086c83si3280294pjb.99.2022.06.21.10.23.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jun 2022 10:23:44 -0700 (PDT) Received-SPF: pass (google.com: domain of mptcp+bounces-5745-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ilajmhys; spf=pass (google.com: domain of mptcp+bounces-5745-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 139.178.88.99 as permitted sender) smtp.mailfrom="mptcp+bounces-5745-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 538CC280BD1 for ; Tue, 21 Jun 2022 17:23:44 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DEAC24C94; Tue, 21 Jun 2022 17:23:42 +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 73CEE747B for ; Tue, 21 Jun 2022 17:23:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655832220; 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=IlajmhysZYJMxcXaYYDNx/6g1cmw5LoLfjCkHgjl7BEY3Y4HaaVb4ErIbzHzqM2oKSR+XW j9QNEXDyNUlFP6MrkZyj9GjEruDYpK+QenNqNW3HJum4eqpqnN17Qvuj54KNLKZ49/BaF4 iuBn63rK3HMFcuY/czlWvVekWmAWV4U= 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-338-qz_yJ3xlM1eJ5gyQnMoc9A-1; Tue, 21 Jun 2022 13:23:39 -0400 X-MC-Unique: qz_yJ3xlM1eJ5gyQnMoc9A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DB045811E7A for ; Tue, 21 Jun 2022 17:23:38 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.39.193.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4F14240CFD0A for ; Tue, 21 Jun 2022 17:23:38 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH v5 mptcp-net 5/6] mptcp: consistent map handling on failure Date: Tue, 21 Jun 2022 19:23:16 +0200 Message-Id: <1d9852cc1346d6cec5f18153d821aae69cb1840b.1655829222.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.1 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