From nobody Thu Sep 18 08:19:15 2025 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:a17:907:7811:b0:6d8:2910:9a8 with SMTP id la17csp297551ejc; Wed, 15 Jun 2022 02:17:15 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t2dZXCoWXfCTVMr30WS5GfDQix/iqgEeY761vUq8m2qgN1GLv6TiOelDUUlzcC/JrQ0c3G X-Received: by 2002:a05:6a00:1da5:b0:522:cb12:549b with SMTP id z37-20020a056a001da500b00522cb12549bmr658431pfw.81.1655284635157; Wed, 15 Jun 2022 02:17:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655284635; cv=none; d=google.com; s=arc-20160816; b=wM58jpQmEmI1Pt1GLqQjzJoD5qp2ciuo1K0iaGtiY9aSCQ0QJiQ2i4UaWdVsHw5+rm ENouE2n7wdZ0F7PUpUoDO3Jw8WEuGf2dKj1T2sdVL+ju6QPXVCDw4wEIzu90FChWe0Vb ayAW2IVGR5L3tjnCg+YGZphW9UuJ1bkRIPeiC5xltxs1F8FoBYnaROTuLq4KQ8Ip+2qM +u9Ivdftb2SdqR2LD0H2axVEVstBvjPZt8HETirIv9nInkcLcsiIlmqWPBdouETwcAB/ toyUApj+xJdmnuarSZVifs7MchGz26OOkMjiwwj9c1wJAXY18NgBW0No+F5pBnoqIXIX SeYA== 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=tkYNLwyx1aaTwLocOhCpMZaxXBm0aiT2/8LXgSJ1PjNPrOP0EcZ+7iXkiJC1DOi93f dk8lOCGGA+lNLcThKCduO61XAkXyMRWuN3ITr2/qLry/66iNRxqcuRGs1Olo1OcnBVIr /NxJ7qGtNJNIbMBvgBUDaB80c/dWJDsjI9hJbo5HW+zsaSpQpiCoCRHTWg4QCV8vSXWH 35hjQ1gSEhRsh/zYb1i0CDrQWQnDNlLrxjQdc6v2LCpBABVJaSbmOq8xf0bfIIC5SG6H S8Zv5TP0ZOO+mP+MxYSDLQMVRYsXj6xEvO+jg79KuqZwVKu5tLOPfV6SXsZo3XYaqPAB 81GQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M6KD87MD; spf=pass (google.com: domain of mptcp+bounces-5655-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="mptcp+bounces-5655-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 h9-20020a170902f70900b00168e8b8db68si7068118plo.105.2022.06.15.02.17.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jun 2022 02:17:15 -0700 (PDT) Received-SPF: pass (google.com: domain of mptcp+bounces-5655-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=M6KD87MD; spf=pass (google.com: domain of mptcp+bounces-5655-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="mptcp+bounces-5655-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 75B05280AB7 for ; Wed, 15 Jun 2022 09:17:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 23D0E23BD; Wed, 15 Jun 2022 09:17:10 +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.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 C328623B9 for ; Wed, 15 Jun 2022 09:17:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655284627; 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=M6KD87MDXrQJ5Tb94EOxqZRWoo7+Fm1nQm0GvguQzh8b+GycQ7KZi/UERYJn6IUg4VzLqN CGi0CC9chAwgYbs+FUO1u0JZse/YvdiMUvFu2U6t5TySPUf6ak7J/0DRsY3I4VS3cXKztu 77QWR5JTj/1hryrCQcp9aV73th+ObGs= 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-611-dq32oLHiP_2qDt90JgfBOA-1; Wed, 15 Jun 2022 05:17:06 -0400 X-MC-Unique: dq32oLHiP_2qDt90JgfBOA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 677F180B70A for ; Wed, 15 Jun 2022 09:17:06 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.39.193.220]) by smtp.corp.redhat.com (Postfix) with ESMTP id EB7DEC23DBF for ; Wed, 15 Jun 2022 09:17:05 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH mptcp-net 5/5] mptcp: consistent map handling on failure Date: Wed, 15 Jun 2022 11:16:16 +0200 Message-Id: <979dc4297888128f0d058ba7631e17415b894666.1655283387.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.8 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