From nobody Mon May 25 03:41:44 2026 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (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 7ACB231AA8F for ; Thu, 7 May 2026 12:26:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778156802; cv=none; b=CPINiuQgjOiz2/3KCMkZjKqxmjN5v/YEpCSw71EmRCjDWrxSBTkUcvmCRBiFa3TP6MmkOwbM0+Ghsoc6895+/qkJAEiS6ugE3qGom1obWPyXfFmZWijgcz7o+o5eIuuM2gyCxiYGJ6/NfYONy0CyAMIbT444FipujATIhGG1L7Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778156802; c=relaxed/simple; bh=eMFG68upAmLsWxiMAxb1IeucRAS9XcLP6Cl75ZadINY=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=p53afztA3x3SJKygTrU2kz7G91nEWN49X2k+ZyWKvtyOhAG1v4xIMJzlxKql8YoJVQ6g9ycSvo1qAv8b+J9itgnjkEpUnvTOk8pZp72vqbm2NUJm73OvCImuS+enAXNGJQxJJBeav7V/ynR082NC75HQI0U70Hi6+Tsqokhu+Ys= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=qqG7DJfS; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="qqG7DJfS" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=8s66CzIdiweecbZohbgyMGsLwRWreTi3FQtn46xdxyk=; b=qqG7DJfSUt3UuRjXUmUtuYTv+YlTCUMjnK5x0zxxeb8g/pToOs/kUhXhWONsp/exbPgOMrs2w TehIUnMOJSBPSF/PhKCLMVqctFVrTan5fuDjsWZw1tTSlrjcf/PWKfLV2J3pzzsfLuRcZ1uryaV ehBq3/O/VFue7Ih9JA7ZuaI= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4gBBBk2XzMz12LCf for ; Thu, 7 May 2026 20:19:26 +0800 (CST) Received: from kwepemj500018.china.huawei.com (unknown [7.202.194.48]) by mail.maildlp.com (Postfix) with ESMTPS id E91EF40538 for ; Thu, 7 May 2026 20:26:34 +0800 (CST) Received: from huawei.com (10.50.85.128) by kwepemj500018.china.huawei.com (7.202.194.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 7 May 2026 20:26:34 +0800 From: Li Xiasong To: CC: , , Subject: [PATCH mptcp-net v3 1/2] mptcp: pm: fix ADD_ADDR timer infinite retry on option space insufficient Date: Thu, 7 May 2026 20:52:23 +0800 Message-ID: <20260507125224.3536507-2-lixiasong1@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260507125224.3536507-1-lixiasong1@huawei.com> References: <20260507125224.3536507-1-lixiasong1@huawei.com> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemj500018.china.huawei.com (7.202.194.48) Content-Type: text/plain; charset="utf-8" When TCP option space is insufficient (e.g., when sending ADD_ADDR with an IPv6 address and port while tcp_timestamps is enabled), the original code jumped to out_unlock without clearing the addr_signal flag. This caused mptcp_pm_add_timer to keep rescheduling indefinitely, not sending ADD_ADDR, preventing subsequent addresses in the endpoint list from being announced. Handle this case by clearing the ADD_ADDR signal and skipping the matching ADD_ADDR retransmission entry. The skip path cancels the matching timer (with id check) and advances PM state progression, preserving forward progress to subsequent PM work. This cancellation is inherently best-effort. A concurrent add_timer callback may already be running and may acquire pm.lock before the cancel path updates entry state. In that case, one final ADD_ADDR transmit attempt can still be executed. Once the cancel path sets entry->retrans_times to ADD_ADDR_RETRANS_MAX, the callback-side retrans_times check suppresses further ADD_ADDR retransmissions. Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Signed-off-by: Li Xiasong Reviewed-by: Matthieu Baerts (NGI0) --- net/mptcp/pm.c | 56 +++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 46 insertions(+), 10 deletions(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 57a456690406..8a86f1e93b78 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -351,7 +351,13 @@ static void mptcp_pm_add_timer(struct timer_list *time= r) =20 spin_lock_bh(&msk->pm.lock); =20 - if (!mptcp_pm_should_add_signal_addr(msk)) { + /* The cancel path (mptcp_pm_del_add_timer()) can race with this + * callback. Once cancel updates retrans_times to MAX, suppress further + * retransmissions here. If this callback acquires pm.lock first, one + * final transmit attempt is still possible. + */ + if (entry->retrans_times < ADD_ADDR_RETRANS_MAX && + !mptcp_pm_should_add_signal_addr(msk)) { pr_debug("retransmit ADD_ADDR id=3D%d\n", entry->addr.id); mptcp_pm_announce_addr(msk, &entry->addr, false); mptcp_pm_add_addr_send_ack(msk); @@ -394,8 +400,12 @@ mptcp_pm_del_add_timer(struct mptcp_sock *msk, /* Note: entry might have been removed by another thread. * We hold rcu_read_lock() to ensure it is not freed under us. */ - if (stop_timer) - sk_stop_timer_sync(sk, &entry->add_timer); + if (stop_timer) { + if (check_id) + sk_stop_timer(sk, &entry->add_timer); + else + sk_stop_timer_sync(sk, &entry->add_timer); + } =20 rcu_read_unlock(); return entry; @@ -860,6 +870,7 @@ bool mptcp_pm_add_addr_signal(struct mptcp_sock *msk, c= onst struct sk_buff *skb, struct mptcp_addr_info *addr, bool *echo, bool *drop_other_suboptions) { + bool skip_add_addr =3D false; int ret =3D false; u8 add_addr; u8 family; @@ -881,24 +892,49 @@ bool mptcp_pm_add_addr_signal(struct mptcp_sock *msk,= const struct sk_buff *skb, } =20 *echo =3D mptcp_pm_should_add_signal_echo(msk); - port =3D !!(*echo ? msk->pm.remote.port : msk->pm.local.port); - - family =3D *echo ? msk->pm.remote.family : msk->pm.local.family; - if (remaining < mptcp_add_addr_len(family, *echo, port)) - goto out_unlock; - if (*echo) { *addr =3D msk->pm.remote; add_addr =3D msk->pm.addr_signal & ~BIT(MPTCP_ADD_ADDR_ECHO); + port =3D !!msk->pm.remote.port; + family =3D msk->pm.remote.family; } else { *addr =3D msk->pm.local; add_addr =3D msk->pm.addr_signal & ~BIT(MPTCP_ADD_ADDR_SIGNAL); + port =3D !!msk->pm.local.port; + family =3D msk->pm.local.family; } - WRITE_ONCE(msk->pm.addr_signal, add_addr); + + if (remaining < mptcp_add_addr_len(family, *echo, port)) { + struct net *net =3D sock_net((struct sock *)msk); + + if (!*drop_other_suboptions) + goto out_unlock; + + if (*echo) { + MPTCP_INC_STATS(net, MPTCP_MIB_ECHOADDTXDROP); + } else { + skip_add_addr =3D true; + MPTCP_INC_STATS(net, MPTCP_MIB_ADDADDRTXDROP); + } + goto drop_signal_mark; + } + ret =3D true; =20 +drop_signal_mark: + WRITE_ONCE(msk->pm.addr_signal, add_addr); + out_unlock: spin_unlock_bh(&msk->pm.lock); + + /* On pure-ACK option-space exhaustion, stop retrying this ADD_ADDR: + * clear the signal bit, cancel the matching retransmission timer, and + * let the PM state machine progress. + */ + if (skip_add_addr) { + mptcp_pm_del_add_timer(msk, addr, true); + mptcp_pm_subflow_established(msk); + } return ret; } =20 --=20 2.34.1 From nobody Mon May 25 03:41:44 2026 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (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 0931B31AA8F for ; Thu, 7 May 2026 12:26:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778156805; cv=none; b=h+i00y2Oo4s0ux3C4dGQjOY6GwZSQ45bASxXBWlDgqBVtW1dYLRXS2lKwro89DgdYo3kUJDBTww1e9AGdLZxyVMKHcNFF2lirNsMiZN2NPNQKDkRbp9qdEzFAPhnGAQRen8FSwuR0P3DBeEle6QQjxgK191dJf9xPDi34MK35ME= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778156805; c=relaxed/simple; bh=QQ8D1JZpQQMjOfIgBYlk2gLK9nkRvftK+ptNDNMXemY=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uP9qF0SVMMAtJIPkWL/jeWszT0WvZ4ZZXr6+drFunh79VjiT0f7zre3LPogQLnxuYkMEHZyRQC8b1840teNX/EU8DI3old6iV0r18+iHWeKfzi93za4bCpv6OtwyUfGV14ThRbWxZXrj/xqweEjh7jvz6/eIZSvYjvh1lU6XViY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=X3hn7HC/; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="X3hn7HC/" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=YXcX/3fRPBh5vW6oDfBLplj0huueVK1I6L/NkoC/KT8=; b=X3hn7HC/lwwHrH3xSJcI7n/noTMKhNNH7urONXw/M58EqDt8Mi3ebqh43dWxBqAFCs++B1uOy 2CkbdL4OYbwPj7tX8A8tPWoy8w7BA4pX2TTsOYw6Sjm1aPPSFrA5d+aGo2bo9/CRuEZULy1mLzw P+btN+fZOxZeomtSleoFf9c= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4gBBBG0F6vzRhQT for ; Thu, 7 May 2026 20:19:02 +0800 (CST) Received: from kwepemj500018.china.huawei.com (unknown [7.202.194.48]) by mail.maildlp.com (Postfix) with ESMTPS id 3965F40569 for ; Thu, 7 May 2026 20:26:35 +0800 (CST) Received: from huawei.com (10.50.85.128) by kwepemj500018.china.huawei.com (7.202.194.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 7 May 2026 20:26:34 +0800 From: Li Xiasong To: CC: , , Subject: [PATCH mptcp-net v3 2/2] selftests: mptcp: join: cover ADD_ADDR tx drop and list progress Date: Thu, 7 May 2026 20:52:24 +0800 Message-ID: <20260507125224.3536507-3-lixiasong1@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260507125224.3536507-1-lixiasong1@huawei.com> References: <20260507125224.3536507-1-lixiasong1@huawei.com> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemj500018.china.huawei.com (7.202.194.48) Content-Type: text/plain; charset="utf-8" Extend add_addr_ports_tests with IPv6 signaling cases that exercise ADD_ADDR tx-space shortage when tcp_timestamps are enabled. Add one case to verify PM still progresses to later signal endpoints after the first one is dropped. This covers both failure accounting and the non-blocking behavior of the announce list after a tx-space drop on pure ACK. Signed-off-by: Li Xiasong Reviewed-by: Matthieu Baerts (NGI0) --- .../testing/selftests/net/mptcp/mptcp_join.sh | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index beec41f6662a..5acd12021e6e 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1828,6 +1828,22 @@ chk_add_tx_nr() fi } =20 +chk_add_drop_tx_nr() +{ + local drop_tx_nr=3D$1 + local count + + print_check "add addr tx drop" + count=3D$(mptcp_lib_get_counter ${ns1} "MPTcpExtAddAddrTxDrop") + if [ -z "$count" ]; then + print_skip + elif [ "$count" !=3D "$drop_tx_nr" ]; then + fail_test "got $count ADD_ADDR drop[s] TX, expected $drop_tx_nr" + else + print_ok + fi +} + chk_rm_nr() { local rm_addr_nr=3D$1 @@ -3278,6 +3294,21 @@ add_addr_ports_tests() =20 chk_mpc_endp_attempt ${retl} 1 fi + + # first signal address drops, second one still progresses + if reset "signal addr list progresses after tx drop"; then + pm_nl_set_limits $ns1 0 2 + pm_nl_set_limits $ns2 1 0 + ip netns exec $ns1 sysctl -q net.ipv4.tcp_timestamps=3D1 + ip netns exec $ns2 sysctl -q net.ipv4.tcp_timestamps=3D1 + + pm_nl_add_endpoint $ns1 dead:beef:2::1 flags signal port 10100 + pm_nl_add_endpoint $ns1 dead:beef:3::1 flags signal + run_tests $ns1 $ns2 dead:beef:1::1 + chk_add_drop_tx_nr 1 + chk_add_tx_nr 1 1 + chk_add_nr 1 1 0 + fi } =20 bind_tests() --=20 2.34.1