MPTCP Linux Development
 help / color / mirror / Atom feed
* [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info
@ 2026-08-25 11:33 Kalpan Jani
  2026-08-25 11:51 ` sashiko-bot
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Kalpan Jani @ 2026-08-25 11:33 UTC (permalink / raw)
  To: mptcp
  Cc: matttbe, martineau, pabeni, shardul.b, janak, kalpanjani009,
	Kalpan Jani

mptcpi_write_seq, mptcpi_snd_una and mptcpi_rcv_nxt report the raw
64-bit data sequence numbers, seeded from the connection's IDSN/IASN.
Since the IDSN/IASN come from mptcp_crypto_key_sha(), these fields
carry an effectively random offset and are not useful to userspace as
absolute values: a caller has to snapshot two getsockopt(MPTCP_INFO)
calls and subtract to get anything meaningful, which is exactly what
tools/testing/selftests/net/mptcp/mptcp_sockopt.c already does.

mptcp_info also reports mptcpi_bytes_sent, mptcpi_bytes_received and
mptcpi_bytes_acked, which give the same information as a plain byte
count starting at 0. The snapshot-and-diff workaround for the seq
fields is redundant once those are available.

Cache the local and remote initial sequence numbers on the
mptcp_sock the same way ->token already is, and subtract them in
mptcp_diag_fill_info(), so mptcpi_write_seq, mptcpi_snd_una and
mptcpi_rcv_nxt also start near 0 for a freshly established
connection.

msk->local_idsn is set at every place write_seq is seeded from
subflow->idsn: the provisional value in __mptcp_sync_state() at
TCP_SYN_SENT, the authoritative one in mptcp_connect(), and the
passive/accept-side value in mptcp_sk_clone_init(). Missing the
first of these would leave a window where a concurrent
getsockopt(MPTCP_INFO) still saw the raw, un-normalized write_seq.

The TCP-fallback path never negotiates an IASN, so msk->remote_idsn
stays at its zero-initialized default there, which is a no-op for
the subtraction and leaves mptcpi_rcv_nxt reporting the plain TCP
sequence number as before.

Link: https://github.com/multipath-tcp/mptcp_net-next/issues/445
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
---
 net/mptcp/protocol.c | 3 +++
 net/mptcp/protocol.h | 7 +++++++
 net/mptcp/sockopt.c  | 6 +++---
 net/mptcp/subflow.c  | 2 ++
 4 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index f22d64ab1c53b..47faece545f15 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3764,6 +3764,7 @@ struct sock *mptcp_sk_clone_init(const struct sock *sk,
 	msk = mptcp_sk(nsk);
 	WRITE_ONCE(msk->local_key, subflow_req->local_key);
 	WRITE_ONCE(msk->token, subflow_req->token);
+	WRITE_ONCE(msk->local_idsn, subflow_req->idsn);
 	msk->in_accept_queue = 1;
 	WRITE_ONCE(msk->fully_established, false);
 	if (mp_opt->suboptions & OPTION_MPTCP_CSUMREQD)
@@ -4204,6 +4205,8 @@ static int mptcp_connect(struct sock *sk, struct sockaddr_unsized *uaddr,
 	WRITE_ONCE(msk->write_seq, subflow->idsn);
 	WRITE_ONCE(msk->snd_nxt, subflow->idsn);
 	WRITE_ONCE(msk->snd_una, subflow->idsn);
+	WRITE_ONCE(msk->local_idsn, subflow->idsn);
+
 	if (likely(!__mptcp_check_fallback(msk)))
 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEACTIVE);
 
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 3d250e8204d52..c1a709b2287f0 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -306,6 +306,13 @@ struct mptcp_sock {
 	u64		bytes_acked;
 	u64		snd_una;
 	u64		wnd_end;
+	/*
+	 * cached IDSN/IASN, so mptcp_diag_fill_info() can report
+	 * write_seq/snd_una/rcv_nxt normalized to start near 0
+	 * instead of the raw, crypto-derived initial values.
+	 */
+	u64		local_idsn;
+	u64		remote_idsn;
 	u32		last_data_sent;
 	u32		last_data_recv;
 	u32		last_ack_recv;
diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 922f6ae5c80cb..fb3dfa88eba5a 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -1086,7 +1086,7 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
 	slow = lock_sock_fast(sk);
 	info->mptcpi_csum_enabled = READ_ONCE(msk->csum_enabled);
 	info->mptcpi_token = msk->token;
-	info->mptcpi_write_seq = msk->write_seq;
+	info->mptcpi_write_seq = msk->write_seq - msk->local_idsn;
 	info->mptcpi_retransmits = inet_csk(sk)->icsk_retransmits;
 	info->mptcpi_bytes_sent = msk->bytes_sent;
 	info->mptcpi_bytes_received = msk->bytes_received;
@@ -1100,8 +1100,8 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
 
 	mptcp_data_lock(sk);
 	info->mptcpi_last_ack_recv = jiffies_to_msecs(now - msk->last_ack_recv);
-	info->mptcpi_snd_una = msk->snd_una;
-	info->mptcpi_rcv_nxt = msk->ack_seq;
+	info->mptcpi_snd_una = msk->snd_una - msk->local_idsn;
+	info->mptcpi_rcv_nxt = msk->ack_seq - msk->remote_idsn;
 	info->mptcpi_bytes_acked = msk->bytes_acked;
 	mptcp_data_unlock(sk);
 }
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 2d7ccb01d2342..70e187694d6a5 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -466,6 +466,7 @@ void __mptcp_sync_state(struct sock *sk, int state)
 		 * even for the FASTOPEN scenarios
 		 */
 		WRITE_ONCE(msk->write_seq, subflow->idsn + 1);
+		WRITE_ONCE(msk->local_idsn, subflow->idsn);
 		WRITE_ONCE(msk->snd_nxt, msk->write_seq);
 		mptcp_set_state(sk, state);
 		sk->sk_state_change(sk);
@@ -492,6 +493,7 @@ static void subflow_set_remote_key(struct mptcp_sock *msk,
 
 	WRITE_ONCE(msk->remote_key, subflow->remote_key);
 	WRITE_ONCE(msk->ack_seq, subflow->iasn);
+	WRITE_ONCE(msk->remote_idsn, subflow->iasn);
 	WRITE_ONCE(msk->can_ack, true);
 	atomic64_set(&msk->rcv_wnd_sent, subflow->iasn);
 }
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info
  2026-08-25 11:33 [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info Kalpan Jani
@ 2026-08-25 11:51 ` sashiko-bot
  2026-08-25 12:48 ` MPTCP CI
  2026-08-26  6:03 ` [PATCH net-next v2] " Kalpan Jani
  2 siblings, 0 replies; 6+ messages in thread
From: sashiko-bot @ 2026-08-25 11:51 UTC (permalink / raw)
  To: Kalpan Jani; +Cc: mptcp

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Asymmetric normalization of local and remote sequence numbers creates an off-by-one inconsistency in MPTCP_INFO.
--

--- Patch [1]: [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info ---
commit 6231029f4c06cd4480ab1f97fc9151acd4862390
Author: Kalpan Jani <kalpan.jani@mpiricsoftware.com>

mptcp: normalize seq numbers reported in mptcp_info

This commit normalizes the sequence numbers reported by mptcp_info.
It caches the local and remote initial sequence numbers and subtracts them
in mptcp_diag_fill_info() so the diagnostic fields start near 0.

Link: https://github.com/multipath-tcp/mptcp_net-next/issues/445

> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index fcf6feb2a9eb5..0468099b19bfc 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
[ ... ]
> @@ -1010,7 +1010,7 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
>  	slow = lock_sock_fast(sk);
>  	info->mptcpi_csum_enabled = READ_ONCE(msk->csum_enabled);
>  	info->mptcpi_token = msk->token;
> -	info->mptcpi_write_seq = msk->write_seq;
> +	info->mptcpi_write_seq = msk->write_seq - msk->local_idsn;
>  	info->mptcpi_retransmits = inet_csk(sk)->icsk_retransmits;
>  	info->mptcpi_bytes_sent = msk->bytes_sent;
>  	info->mptcpi_bytes_received = msk->bytes_received;
[ ... ]
> @@ -1024,8 +1024,8 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
>  
>  	mptcp_data_lock(sk);
>  	info->mptcpi_last_ack_recv = jiffies_to_msecs(now - msk->last_ack_recv);
> -	info->mptcpi_snd_una = msk->snd_una;
> -	info->mptcpi_rcv_nxt = msk->ack_seq;
> +	info->mptcpi_snd_una = msk->snd_una - msk->local_idsn;
> +	info->mptcpi_rcv_nxt = msk->ack_seq - msk->remote_idsn;
>  	info->mptcpi_bytes_acked = msk->bytes_acked;
>  	mptcp_data_unlock(sk);
>  }
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index af81ad5e699d1..4fa19835c4055 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -465,6 +465,7 @@ void __mptcp_sync_state(struct sock *sk, int state)
>  		 * even for the FASTOPEN scenarios
>  		 */
>  		WRITE_ONCE(msk->write_seq, subflow->idsn + 1);
> +		WRITE_ONCE(msk->local_idsn, subflow->idsn);
>  		WRITE_ONCE(msk->snd_nxt, msk->write_seq);
>  		mptcp_set_state(sk, state);
>  		sk->sk_state_change(sk);
[ ... ]
> @@ -491,6 +492,7 @@ static void subflow_set_remote_key(struct mptcp_sock *msk,
>  
>  	WRITE_ONCE(msk->remote_key, subflow->remote_key);
>  	WRITE_ONCE(msk->ack_seq, subflow->iasn);
> +	WRITE_ONCE(msk->remote_idsn, subflow->iasn);

[Severity: Medium]
Will this result in an asymmetric baseline where mptcpi_write_seq and
mptcpi_snd_una start at 1, while mptcpi_rcv_nxt starts at 0?

Looking at subflow_set_remote_key(), subflow->iasn is incremented before it is
assigned to msk->remote_idsn:

	mptcp_crypto_key_sha(subflow->remote_key, NULL, &subflow->iasn);
	subflow->iasn++;

However, in __mptcp_sync_state(), msk->local_idsn is assigned the unincremented
subflow->idsn:

	WRITE_ONCE(msk->write_seq, subflow->idsn + 1);
	WRITE_ONCE(msk->local_idsn, subflow->idsn);

When these are subtracted in mptcp_diag_fill_info(), msk->write_seq (which is
subflow->idsn + 1) minus msk->local_idsn results in 1, while msk->ack_seq minus
msk->remote_idsn results in 0.

Should msk->local_idsn and msk->remote_idsn both use either the incremented or
unincremented hash to ensure the normalized sequences start at the same value?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825113355.3573376-1-kalpan.jani@mpiricsoftware.com?part=1

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info
  2026-08-25 11:33 [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info Kalpan Jani
  2026-08-25 11:51 ` sashiko-bot
@ 2026-08-25 12:48 ` MPTCP CI
  2026-08-26  6:03 ` [PATCH net-next v2] " Kalpan Jani
  2 siblings, 0 replies; 6+ messages in thread
From: MPTCP CI @ 2026-08-25 12:48 UTC (permalink / raw)
  To: Kalpan Jani; +Cc: mptcp

Hi Kalpan,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/32845186022

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/663fdcb90bfa
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1151476


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH net-next v2] mptcp: normalize seq numbers reported in mptcp_info
  2026-08-25 11:33 [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info Kalpan Jani
  2026-08-25 11:51 ` sashiko-bot
  2026-08-25 12:48 ` MPTCP CI
@ 2026-08-26  6:03 ` Kalpan Jani
  2026-08-26  7:26   ` MPTCP CI
  2026-08-26  9:48   ` Kalpan Jani
  2 siblings, 2 replies; 6+ messages in thread
From: Kalpan Jani @ 2026-08-26  6:03 UTC (permalink / raw)
  To: mptcp
  Cc: matttbe, martineau, pabeni, shardul.b, janak, kalpanjani009,
	Kalpan Jani

mptcpi_write_seq, mptcpi_snd_una and mptcpi_rcv_nxt report the raw
64-bit data sequence numbers, seeded from the connection's IDSN/IASN.
Since the IDSN/IASN come from mptcp_crypto_key_sha(), these fields
carry an effectively random offset and are not useful to userspace as
absolute values: a caller has to snapshot two getsockopt(MPTCP_INFO)
calls and subtract to get anything meaningful, which is exactly what
tools/testing/selftests/net/mptcp/mptcp_sockopt.c already does.

mptcp_info also reports mptcpi_bytes_sent, mptcpi_bytes_received and
mptcpi_bytes_acked, which give the same information as a plain byte
count starting at 0. The snapshot-and-diff workaround for the seq
fields is redundant once those are available.

Cache the local and remote initial sequence numbers on the
mptcp_sock the same way ->token already is, and subtract them in
mptcp_diag_fill_info(), so mptcpi_write_seq, mptcpi_snd_una and
mptcpi_rcv_nxt also start near 0 for a freshly established
connection.

msk->local_idsn is set at every place write_seq is seeded from
subflow->idsn: the provisional value in __mptcp_sync_state() at
TCP_SYN_SENT, the authoritative one in mptcp_connect(), and the
passive/accept-side value in mptcp_sk_clone_init(). Missing the
first of these would leave a window where a concurrent
getsockopt(MPTCP_INFO) still saw the raw, un-normalized write_seq.

msk->remote_idsn is cached from subflow->iasn in
subflow_set_remote_key() before iasn is incremented for the peer's
virtual SYN, so it lines up with the point local_idsn is cached
relative to write_seq's own +1.

The TCP-fallback path never negotiates an IASN, so msk->remote_idsn
stays at its zero-initialized default there, which is a no-op for
the subtraction and leaves mptcpi_rcv_nxt reporting the plain TCP
sequence number as before.

Link: https://github.com/multipath-tcp/mptcp_net-next/issues/445
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
---

Changes since v1:
- cached msk->remote_idsn before subflow->iasn++ instead of after:
  the increment accounts for the peer's virtual SYN, and caching
  remote_idsn post-increment left mptcpi_rcv_nxt starting at 0 while
  mptcpi_write_seq/mptcpi_snd_una started at 1 for the same
  connection.

v1: https://lore.kernel.org/all/20260825113355.3573376-1-kalpan.jani@mpiricsoftware.com/

---
 net/mptcp/protocol.c | 3 +++
 net/mptcp/protocol.h | 7 +++++++
 net/mptcp/sockopt.c  | 6 +++---
 net/mptcp/subflow.c  | 2 ++
 4 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index f22d64ab1c53b..47faece545f15 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3764,6 +3764,7 @@ struct sock *mptcp_sk_clone_init(const struct sock *sk,
 	msk = mptcp_sk(nsk);
 	WRITE_ONCE(msk->local_key, subflow_req->local_key);
 	WRITE_ONCE(msk->token, subflow_req->token);
+	WRITE_ONCE(msk->local_idsn, subflow_req->idsn);
 	msk->in_accept_queue = 1;
 	WRITE_ONCE(msk->fully_established, false);
 	if (mp_opt->suboptions & OPTION_MPTCP_CSUMREQD)
@@ -4204,6 +4205,8 @@ static int mptcp_connect(struct sock *sk, struct sockaddr_unsized *uaddr,
 	WRITE_ONCE(msk->write_seq, subflow->idsn);
 	WRITE_ONCE(msk->snd_nxt, subflow->idsn);
 	WRITE_ONCE(msk->snd_una, subflow->idsn);
+	WRITE_ONCE(msk->local_idsn, subflow->idsn);
+
 	if (likely(!__mptcp_check_fallback(msk)))
 		MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEACTIVE);
 
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 3d250e8204d52..c1a709b2287f0 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -306,6 +306,13 @@ struct mptcp_sock {
 	u64		bytes_acked;
 	u64		snd_una;
 	u64		wnd_end;
+	/*
+	 * cached IDSN/IASN, so mptcp_diag_fill_info() can report
+	 * write_seq/snd_una/rcv_nxt normalized to start near 0
+	 * instead of the raw, crypto-derived initial values.
+	 */
+	u64		local_idsn;
+	u64		remote_idsn;
 	u32		last_data_sent;
 	u32		last_data_recv;
 	u32		last_ack_recv;
diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 922f6ae5c80cb..fb3dfa88eba5a 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -1086,7 +1086,7 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
 	slow = lock_sock_fast(sk);
 	info->mptcpi_csum_enabled = READ_ONCE(msk->csum_enabled);
 	info->mptcpi_token = msk->token;
-	info->mptcpi_write_seq = msk->write_seq;
+	info->mptcpi_write_seq = msk->write_seq - msk->local_idsn;
 	info->mptcpi_retransmits = inet_csk(sk)->icsk_retransmits;
 	info->mptcpi_bytes_sent = msk->bytes_sent;
 	info->mptcpi_bytes_received = msk->bytes_received;
@@ -1100,8 +1100,8 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
 
 	mptcp_data_lock(sk);
 	info->mptcpi_last_ack_recv = jiffies_to_msecs(now - msk->last_ack_recv);
-	info->mptcpi_snd_una = msk->snd_una;
-	info->mptcpi_rcv_nxt = msk->ack_seq;
+	info->mptcpi_snd_una = msk->snd_una - msk->local_idsn;
+	info->mptcpi_rcv_nxt = msk->ack_seq - msk->remote_idsn;
 	info->mptcpi_bytes_acked = msk->bytes_acked;
 	mptcp_data_unlock(sk);
 }
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 2d7ccb01d2342..9a4a818552290 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -466,6 +466,7 @@ void __mptcp_sync_state(struct sock *sk, int state)
 		 * even for the FASTOPEN scenarios
 		 */
 		WRITE_ONCE(msk->write_seq, subflow->idsn + 1);
+		WRITE_ONCE(msk->local_idsn, subflow->idsn);
 		WRITE_ONCE(msk->snd_nxt, msk->write_seq);
 		mptcp_set_state(sk, state);
 		sk->sk_state_change(sk);
@@ -485,6 +486,7 @@ static void subflow_set_remote_key(struct mptcp_sock *msk,
 	subflow->remote_key_valid = 1;
 	subflow->remote_key = mp_opt->sndr_key;
 	mptcp_crypto_key_sha(subflow->remote_key, NULL, &subflow->iasn);
+	WRITE_ONCE(msk->remote_idsn, subflow->iasn);
 	subflow->iasn++;
 
 	/* for fallback's sake */
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next v2] mptcp: normalize seq numbers reported in mptcp_info
  2026-08-26  6:03 ` [PATCH net-next v2] " Kalpan Jani
@ 2026-08-26  7:26   ` MPTCP CI
  2026-08-26  9:48   ` Kalpan Jani
  1 sibling, 0 replies; 6+ messages in thread
From: MPTCP CI @ 2026-08-26  7:26 UTC (permalink / raw)
  To: Kalpan Jani; +Cc: mptcp

Hi Kalpan,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/32938236918

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/10bc5a274e67
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1151847


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH net-next v2] mptcp: normalize seq numbers reported in mptcp_info
  2026-08-26  6:03 ` [PATCH net-next v2] " Kalpan Jani
  2026-08-26  7:26   ` MPTCP CI
@ 2026-08-26  9:48   ` Kalpan Jani
  1 sibling, 0 replies; 6+ messages in thread
From: Kalpan Jani @ 2026-08-26  9:48 UTC (permalink / raw)
  To: Kalpan Jani
  Cc: mptcp, matttbe, martineau, pabeni, shardul.b, janak,
	kalpanjani009

Hi All, 

I sent the v2 patch in the same thread as v1, and I think that may
be why Sashiko hasn't reviewed it yet.

I'll resend v2 within the next 24 hours to make sure it gets picked
up for review.

Cheers,
Kalpan Jani


From: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
To: <mptcp@lists.linux.dev>
Cc: <matttbe@kernel.org>, <martineau@kernel.org>, <pabeni@redhat.com>, <shardul.b@mpiricsoftware.com>, <janak@mpiric.us>, <kalpanjani009@gmail.com>, "Kalpan Jani"<kalpan.jani@mpiricsoftware.com>
Date: Wed, 26 Aug 2026 11:33:18 +0530
Subject: [PATCH net-next v2] mptcp: normalize seq numbers reported in mptcp_info

 > mptcpi_write_seq, mptcpi_snd_una and mptcpi_rcv_nxt report the raw
 > 64-bit data sequence numbers, seeded from the connection's IDSN/IASN.
 > Since the IDSN/IASN come from mptcp_crypto_key_sha(), these fields
 > carry an effectively random offset and are not useful to userspace as
 > absolute values: a caller has to snapshot two getsockopt(MPTCP_INFO)
 > calls and subtract to get anything meaningful, which is exactly what
 > tools/testing/selftests/net/mptcp/mptcp_sockopt.c already does.
 > 
 > mptcp_info also reports mptcpi_bytes_sent, mptcpi_bytes_received and
 > mptcpi_bytes_acked, which give the same information as a plain byte
 > count starting at 0. The snapshot-and-diff workaround for the seq
 > fields is redundant once those are available.
 > 
 > Cache the local and remote initial sequence numbers on the
 > mptcp_sock the same way ->token already is, and subtract them in
 > mptcp_diag_fill_info(), so mptcpi_write_seq, mptcpi_snd_una and
 > mptcpi_rcv_nxt also start near 0 for a freshly established
 > connection.
 > 
 > msk->local_idsn is set at every place write_seq is seeded from
 > subflow->idsn: the provisional value in __mptcp_sync_state() at
 > TCP_SYN_SENT, the authoritative one in mptcp_connect(), and the
 > passive/accept-side value in mptcp_sk_clone_init(). Missing the
 > first of these would leave a window where a concurrent
 > getsockopt(MPTCP_INFO) still saw the raw, un-normalized write_seq.
 > 
 > msk->remote_idsn is cached from subflow->iasn in
 > subflow_set_remote_key() before iasn is incremented for the peer's
 > virtual SYN, so it lines up with the point local_idsn is cached
 > relative to write_seq's own +1.
 > 
 > The TCP-fallback path never negotiates an IASN, so msk->remote_idsn
 > stays at its zero-initialized default there, which is a no-op for
 > the subtraction and leaves mptcpi_rcv_nxt reporting the plain TCP
 > sequence number as before.
 > 
 > Link: https://github.com/multipath-tcp/mptcp_net-next/issues/445
 > Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
 > ---
 > 
 > Changes since v1:
 > - cached msk->remote_idsn before subflow->iasn++ instead of after:
 >   the increment accounts for the peer's virtual SYN, and caching
 >   remote_idsn post-increment left mptcpi_rcv_nxt starting at 0 while
 >   mptcpi_write_seq/mptcpi_snd_una started at 1 for the same
 >   connection.
 > 
 > v1: https://lore.kernel.org/all/20260825113355.3573376-1-kalpan.jani@mpiricsoftware.com/
 > 
 > ---
 >  net/mptcp/protocol.c | 3 +++
 >  net/mptcp/protocol.h | 7 +++++++
 >  net/mptcp/sockopt.c  | 6 +++---
 >  net/mptcp/subflow.c  | 2 ++
 >  4 files changed, 15 insertions(+), 3 deletions(-)
 > 
 > diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
 > index f22d64ab1c53b..47faece545f15 100644
 > --- a/net/mptcp/protocol.c
 > +++ b/net/mptcp/protocol.c
 > @@ -3764,6 +3764,7 @@ struct sock *mptcp_sk_clone_init(const struct sock *sk,
 >      msk = mptcp_sk(nsk);
 >      WRITE_ONCE(msk->local_key, subflow_req->local_key);
 >      WRITE_ONCE(msk->token, subflow_req->token);
 > +    WRITE_ONCE(msk->local_idsn, subflow_req->idsn);
 >      msk->in_accept_queue = 1;
 >      WRITE_ONCE(msk->fully_established, false);
 >      if (mp_opt->suboptions & OPTION_MPTCP_CSUMREQD)
 > @@ -4204,6 +4205,8 @@ static int mptcp_connect(struct sock *sk, struct sockaddr_unsized *uaddr,
 >      WRITE_ONCE(msk->write_seq, subflow->idsn);
 >      WRITE_ONCE(msk->snd_nxt, subflow->idsn);
 >      WRITE_ONCE(msk->snd_una, subflow->idsn);
 > +    WRITE_ONCE(msk->local_idsn, subflow->idsn);
 > +
 >      if (likely(!__mptcp_check_fallback(msk)))
 >          MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEACTIVE);
 >  
 > diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
 > index 3d250e8204d52..c1a709b2287f0 100644
 > --- a/net/mptcp/protocol.h
 > +++ b/net/mptcp/protocol.h
 > @@ -306,6 +306,13 @@ struct mptcp_sock {
 >      u64        bytes_acked;
 >      u64        snd_una;
 >      u64        wnd_end;
 > +    /*
 > +     * cached IDSN/IASN, so mptcp_diag_fill_info() can report
 > +     * write_seq/snd_una/rcv_nxt normalized to start near 0
 > +     * instead of the raw, crypto-derived initial values.
 > +     */
 > +    u64        local_idsn;
 > +    u64        remote_idsn;
 >      u32        last_data_sent;
 >      u32        last_data_recv;
 >      u32        last_ack_recv;
 > diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
 > index 922f6ae5c80cb..fb3dfa88eba5a 100644
 > --- a/net/mptcp/sockopt.c
 > +++ b/net/mptcp/sockopt.c
 > @@ -1086,7 +1086,7 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
 >      slow = lock_sock_fast(sk);
 >      info->mptcpi_csum_enabled = READ_ONCE(msk->csum_enabled);
 >      info->mptcpi_token = msk->token;
 > -    info->mptcpi_write_seq = msk->write_seq;
 > +    info->mptcpi_write_seq = msk->write_seq - msk->local_idsn;
 >      info->mptcpi_retransmits = inet_csk(sk)->icsk_retransmits;
 >      info->mptcpi_bytes_sent = msk->bytes_sent;
 >      info->mptcpi_bytes_received = msk->bytes_received;
 > @@ -1100,8 +1100,8 @@ void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info)
 >  
 >      mptcp_data_lock(sk);
 >      info->mptcpi_last_ack_recv = jiffies_to_msecs(now - msk->last_ack_recv);
 > -    info->mptcpi_snd_una = msk->snd_una;
 > -    info->mptcpi_rcv_nxt = msk->ack_seq;
 > +    info->mptcpi_snd_una = msk->snd_una - msk->local_idsn;
 > +    info->mptcpi_rcv_nxt = msk->ack_seq - msk->remote_idsn;
 >      info->mptcpi_bytes_acked = msk->bytes_acked;
 >      mptcp_data_unlock(sk);
 >  }
 > diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
 > index 2d7ccb01d2342..9a4a818552290 100644
 > --- a/net/mptcp/subflow.c
 > +++ b/net/mptcp/subflow.c
 > @@ -466,6 +466,7 @@ void __mptcp_sync_state(struct sock *sk, int state)
 >           * even for the FASTOPEN scenarios
 >           */
 >          WRITE_ONCE(msk->write_seq, subflow->idsn + 1);
 > +        WRITE_ONCE(msk->local_idsn, subflow->idsn);
 >          WRITE_ONCE(msk->snd_nxt, msk->write_seq);
 >          mptcp_set_state(sk, state);
 >          sk->sk_state_change(sk);
 > @@ -485,6 +486,7 @@ static void subflow_set_remote_key(struct mptcp_sock *msk,
 >      subflow->remote_key_valid = 1;
 >      subflow->remote_key = mp_opt->sndr_key;
 >      mptcp_crypto_key_sha(subflow->remote_key, NULL, &subflow->iasn);
 > +    WRITE_ONCE(msk->remote_idsn, subflow->iasn);
 >      subflow->iasn++;
 >  
 >      /* for fallback's sake */
 > -- 
 > 2.43.0
 > 
 > 



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-08-26  9:48 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-25 11:33 [PATCH net-next] mptcp: normalize seq numbers reported in mptcp_info Kalpan Jani
2026-08-25 11:51 ` sashiko-bot
2026-08-25 12:48 ` MPTCP CI
2026-08-26  6:03 ` [PATCH net-next v2] " Kalpan Jani
2026-08-26  7:26   ` MPTCP CI
2026-08-26  9:48   ` Kalpan Jani

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox