From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 E90C78F57 for ; Mon, 13 Feb 2023 14:55:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A852C4339B; Mon, 13 Feb 2023 14:55:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1676300142; bh=tCmo0LV+XWnV7qxergCVHAh9vvmWGwpvvGWs2W2mLoU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kGq9+43HdbUBJ/cQpftLcNnMrUJsmRYYeCUViUcm0PgJInuiNlB5yau2muqJEANZg 1hJDKD/2MAlAiElcihiB/eTI86ytQJaBFvlq4aqpRxEtLN6GbibhnA7Qu+EdIKvw3b sPsHDdxG4zcs/PUyg1EPsnwPmTq+szcZ7TR4UfZQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Paolo Abeni , Matthieu Baerts , "David S. Miller" Subject: [PATCH 6.1 080/114] mptcp: be careful on subflow status propagation on errors Date: Mon, 13 Feb 2023 15:48:35 +0100 Message-Id: <20230213144746.294570990@linuxfoundation.org> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230213144742.219399167@linuxfoundation.org> References: <20230213144742.219399167@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Paolo Abeni commit 1249db44a102d9d3541ed7798d4b01ffdcf03524 upstream. Currently the subflow error report callback unconditionally propagates the fallback subflow status to the owning msk. If the msk is already orphaned, the above prevents the code from correctly tracking the msk moving to the TCP_CLOSE state and doing the appropriate cleanup. All the above causes increasing memory usage over time and sporadic self-tests failures. There is a great deal of infrastructure trying to propagate correctly the fallback subflow status to the owning mptcp socket, e.g. via mptcp_subflow_eof() and subflow_sched_work_if_closed(): in the error propagation path we need only to cope with unorphaned sockets. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/339 Fixes: 15cc10453398 ("mptcp: deliver ssk errors to msk") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/mptcp/subflow.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1344,6 +1344,7 @@ void __mptcp_error_report(struct sock *s mptcp_for_each_subflow(msk, subflow) { struct sock *ssk = mptcp_subflow_tcp_sock(subflow); int err = sock_error(ssk); + int ssk_state; if (!err) continue; @@ -1354,7 +1355,14 @@ void __mptcp_error_report(struct sock *s if (sk->sk_state != TCP_SYN_SENT && !__mptcp_check_fallback(msk)) continue; - inet_sk_state_store(sk, inet_sk_state_load(ssk)); + /* We need to propagate only transition to CLOSE state. + * Orphaned socket will see such state change via + * subflow_sched_work_if_closed() and that path will properly + * destroy the msk as needed. + */ + ssk_state = inet_sk_state_load(ssk); + if (ssk_state == TCP_CLOSE && !sock_flag(sk, SOCK_DEAD)) + inet_sk_state_store(sk, ssk_state); sk->sk_err = -err; /* This barrier is coupled with smp_rmb() in mptcp_poll() */