2024-06-07 15:06:29

by Matthieu Baerts (NGI0)

[permalink] [raw]
Subject: [PATCH net 0/4] mptcp: various fixes

The different patches here are some unrelated fixes for MPTCP:

- Patch 1 ensures 'snd_una' is initialised on connect in case of MPTCP
fallback to TCP followed by retransmissions before the processing of
any other incoming packets. A fix for v5.9+.

- Patch 2 makes sure the RmAddr MIB counter is incremented, and only
once per ID, upon the reception of a RM_ADDR. A fix for v5.10+.

- Patch 3 doesn't update 'add addr' related counters if the connect()
was not possible. A fix for v5.7+.

- Patch 4 updates the mailmap file to add Geliang's new email address.

Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
---
Geliang Tang (1):
mailmap: map Geliang's new email address

Paolo Abeni (1):
mptcp: ensure snd_una is properly initialized on connect

YonglongLi (2):
mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID
mptcp: pm: update add_addr counters after connect

.mailmap | 1 +
net/mptcp/pm_netlink.c | 21 ++++++++++++++-------
net/mptcp/protocol.c | 1 +
tools/testing/selftests/net/mptcp/mptcp_join.sh | 5 +++--
4 files changed, 19 insertions(+), 9 deletions(-)
---
base-commit: c44711b78608c98a3e6b49ce91678cd0917d5349
change-id: 20240607-upstream-net-20240607-misc-fixes-024007171d60

Best regards,
--
Matthieu Baerts (NGI0) <[email protected]>



2024-06-07 15:07:00

by Matthieu Baerts (NGI0)

[permalink] [raw]
Subject: [PATCH net 2/4] mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID

From: YonglongLi <[email protected]>

The RmAddr MIB counter is supposed to be incremented once when a valid
RM_ADDR has been received. Before this patch, it could have been
incremented as many times as the number of subflows connected to the
linked address ID, so it could have been 0, 1 or more than 1.

The "RmSubflow" is incremented after a local operation. In this case,
it is normal to tied it with the number of subflows that have been
actually removed.

The "remove invalid addresses" MP Join subtest has been modified to
validate this case. A broadcast IP address is now used instead: the
client will not be able to create a subflow to this address. The
consequence is that when receiving the RM_ADDR with the ID attached to
this broadcast IP address, no subflow linked to this ID will be found.

Fixes: 7a7e52e38a40 ("mptcp: add RM_ADDR related mibs")
Cc: [email protected]
Co-developed-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: YonglongLi <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
---
net/mptcp/pm_netlink.c | 5 ++++-
tools/testing/selftests/net/mptcp/mptcp_join.sh | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index 7f53e022e27e..766a8409fa67 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -814,10 +814,13 @@ static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp_sock *msk,
spin_lock_bh(&msk->pm.lock);

removed = true;
- __MPTCP_INC_STATS(sock_net(sk), rm_type);
+ if (rm_type == MPTCP_MIB_RMSUBFLOW)
+ __MPTCP_INC_STATS(sock_net(sk), rm_type);
}
if (rm_type == MPTCP_MIB_RMSUBFLOW)
__set_bit(rm_id ? rm_id : msk->mpc_endpoint_id, msk->pm.id_avail_bitmap);
+ else if (rm_type == MPTCP_MIB_RMADDR)
+ __MPTCP_INC_STATS(sock_net(sk), rm_type);
if (!removed)
continue;

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index 2b66c5fa71eb..aea314d140c9 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -2250,7 +2250,8 @@ remove_tests()
pm_nl_set_limits $ns1 3 3
pm_nl_add_endpoint $ns1 10.0.12.1 flags signal
pm_nl_add_endpoint $ns1 10.0.3.1 flags signal
- pm_nl_add_endpoint $ns1 10.0.14.1 flags signal
+ # broadcast IP: no packet for this address will be received on ns1
+ pm_nl_add_endpoint $ns1 224.0.0.1 flags signal
pm_nl_set_limits $ns2 3 3
addr_nr_ns1=-3 speed=10 \
run_tests $ns1 $ns2 10.0.1.1

--
2.43.0


2024-06-07 15:07:27

by Matthieu Baerts (NGI0)

[permalink] [raw]
Subject: [PATCH net 4/4] mailmap: map Geliang's new email address

From: Geliang Tang <[email protected]>

Just like my other email addresses, map my new one to kernel.org
account too.

My new email address uses "last name, first name" format, which is
different from my other email addresses. This mailmap is also used
to indicate that it is actually the same person.

Suggested-by: Mat Martineau <[email protected]>
Suggested-by: Matthieu Baerts <[email protected]>
Signed-off-by: Geliang Tang <[email protected]>
Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
---
.mailmap | 1 +
1 file changed, 1 insertion(+)

diff --git a/.mailmap b/.mailmap
index efd9fa867a8e..9af91bd3584b 100644
--- a/.mailmap
+++ b/.mailmap
@@ -217,6 +217,7 @@ Geliang Tang <[email protected]> <[email protected]>
Geliang Tang <[email protected]> <[email protected]>
Geliang Tang <[email protected]> <[email protected]>
Geliang Tang <[email protected]> <[email protected]>
+Geliang Tang <[email protected]> <[email protected]>
Georgi Djakov <[email protected]> <[email protected]>
Gerald Schaefer <[email protected]> <[email protected]>
Gerald Schaefer <[email protected]> <[email protected]>

--
2.43.0


2024-06-07 15:13:09

by Matthieu Baerts (NGI0)

[permalink] [raw]
Subject: [PATCH net 1/4] mptcp: ensure snd_una is properly initialized on connect

From: Paolo Abeni <[email protected]>

This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
is properly initialized on connect"). It turns out that syzkaller can
trigger the retransmit after fallback and before processing any other
incoming packet - so that snd_una is still left uninitialized.

Address the issue explicitly initializing snd_una together with snd_nxt
and write_seq.

Suggested-by: Mat Martineau <[email protected]>
Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect")
Cc: [email protected]
Reported-by: Christoph Paasch <[email protected]>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Mat Martineau <[email protected]>
Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
---
net/mptcp/protocol.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 96b113854bd3..bb7dca8aa2d9 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3740,6 +3740,7 @@ static int mptcp_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)

WRITE_ONCE(msk->write_seq, subflow->idsn);
WRITE_ONCE(msk->snd_nxt, subflow->idsn);
+ WRITE_ONCE(msk->snd_una, subflow->idsn);
if (likely(!__mptcp_check_fallback(msk)))
MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEACTIVE);


--
2.43.0


2024-06-11 03:07:03

by patchwork-bot+netdevbpf

[permalink] [raw]
Subject: Re: [PATCH net 0/4] mptcp: various fixes

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <[email protected]>:

On Fri, 07 Jun 2024 17:01:47 +0200 you wrote:
> The different patches here are some unrelated fixes for MPTCP:
>
> - Patch 1 ensures 'snd_una' is initialised on connect in case of MPTCP
> fallback to TCP followed by retransmissions before the processing of
> any other incoming packets. A fix for v5.9+.
>
> - Patch 2 makes sure the RmAddr MIB counter is incremented, and only
> once per ID, upon the reception of a RM_ADDR. A fix for v5.10+.
>
> [...]

Here is the summary with links:
- [net,1/4] mptcp: ensure snd_una is properly initialized on connect
https://git.kernel.org/netdev/net/c/8031b58c3a9b
- [net,2/4] mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID
https://git.kernel.org/netdev/net/c/6a09788c1a66
- [net,3/4] mptcp: pm: update add_addr counters after connect
https://git.kernel.org/netdev/net/c/40eec1795cc2
- [net,4/4] mailmap: map Geliang's new email address
https://git.kernel.org/netdev/net/c/74acb250e103

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html