From nobody Thu Jun 25 01:57:55 2026 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 883F1481234; Tue, 5 May 2026 15:01:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777993301; cv=none; b=sKBvT3VNrJLjW81dP2Eng4mQA09mOuaIRZlTF0EhaMD6Fs2EG32yxOqPBlIfo/kiPiWz6P4ZYquBD7rCnHY4b0eH5H03+eWFC4hRw9Y4VZMFLmTT4ovVLsgnxHIPsRYCPJYdr0JmQKEZatPayNamCw1LUx907/lDqTTVTGL6m9U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777993301; c=relaxed/simple; bh=wjGGeQFguxsbTAbjtIBBB0sqCBxsMcqIr9guum5PRN0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=eQQ5ugd1UU9FlQo7y1eqdjTVUOfgdS4yaxRxpUcgHNJOEladrzrY8B4XoVdAK6fT50tAFQFm6+2Zt5Aib+1hHVE/wsInVaYLCWr1bNHgnRb9DRSr0AaYmdSgjhcjH1FT+KJ/HQzZ6gHW50H0L7pszDPxiKGmPubvyO/we6jtH+A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M/w8B7I8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M/w8B7I8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AD04C2BCC7; Tue, 5 May 2026 15:01:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777993301; bh=wjGGeQFguxsbTAbjtIBBB0sqCBxsMcqIr9guum5PRN0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=M/w8B7I80qJtEcM19+mII2UjiNAEOtSLhKtDpMbJjXKXelzYd0Kpc5zQYwiKtA59h vvcN+miaJib7hXqbthJBH9rQqNRL3XzNxI8SzNgN17OgKbOpUykh8z2PLvnBboC6OO yBC5nwd8WcFTuOdlGsguWrEH/a31M5kG1aFWdD8E0esEKN0ZbbzgJTxwyTa+bOcqq3 4MVXtyFtiKEoS6IrmNSoZPErz+T6haHvy65ewkXmT49iTINHK5U7053SAyStrecFwi 0ZUtydFQsSDUJVbc7VvG3eIeFruAty7NTDGWI0jLVGw84P3PQphpQCn3gx25FwV4W3 lNPlrJs2i9zxA== From: "Matthieu Baerts (NGI0)" Date: Tue, 05 May 2026 17:00:54 +0200 Subject: [PATCH net 06/11] mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260505-net-mptcp-pm-fixes-7-1-rc3-v1-6-fca8091060a4@kernel.org> References: <20260505-net-mptcp-pm-fixes-7-1-rc3-v1-0-fca8091060a4@kernel.org> In-Reply-To: <20260505-net-mptcp-pm-fixes-7-1-rc3-v1-0-fca8091060a4@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Christoph Paasch Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1632; i=matttbe@kernel.org; h=from:subject:message-id; bh=wjGGeQFguxsbTAbjtIBBB0sqCBxsMcqIr9guum5PRN0=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDJ/sdlv/cajUp9wWthd/uGVhRs0Lmx7ur+t4sS99be53 320Emm71FHKwiDGxSArpsgi3RaZP/N5FW+Jl58FzBxWJpAhDFycAjARuUcM/xMVtphZP01Yull5 bSDH3smJl6KTLs56lDbvSFGwhYSQZR8jQ0PH+QPPCm/qmkxI+HQtSuaP7YcCvo/RVW0N5WV/JQ4 fYQIA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When an ADD_ADDR needs to be retransmitted and another one has already been prepared -- e.g. multiple ADD_ADDRs have been sent in a row and need to be retransmitted later -- this additional retransmission will need to wait. In this case, the timer was reset to TCP_RTO_MAX / 8, which is ~15 seconds. This delay is unnecessary long: it should just be rescheduled at the next opportunity, e.g. after the retransmission timeout. Without this modification, some issues can be seen from time to time in the selftests when multiple ADD_ADDRs are sent, and the host takes time to process them, e.g. the "signal addresses, ADD_ADDR timeout" MPTCP Join selftest, especially with a debug kernel config. Note that on older kernels, 'timeout' is not available. It should be enough to replace it by one second (HZ). Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 8899327e59a1..29d1bb6a69cf 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -342,13 +342,8 @@ static void mptcp_pm_add_timer(struct timer_list *time= r) goto out; } =20 - if (mptcp_pm_should_add_signal_addr(msk)) { - timeout =3D TCP_RTO_MAX / 8; - goto out; - } - timeout =3D mptcp_adjust_add_addr_timeout(msk); - if (!timeout) + if (!timeout || mptcp_pm_should_add_signal_addr(msk)) goto out; =20 spin_lock_bh(&msk->pm.lock); --=20 2.53.0