| Message ID | 20220921125558.19483-5-dmytro@shytyi.net (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Paolo Abeni |
| Headers | show |
| Series | mptcp: Fast Open Mechanism | expand |
| Context | Check | Description |
|---|---|---|
| matttbe/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 43 lines checked |
| matttbe/build | success | Build and static analysis OK |
| matttbe/KVM_Validation__normal | warning | Unstable: 2 failed test(s): selftest_mptfo selftest_simult_flows |
| matttbe/KVM_Validation__debug | warning | Unstable: 1 failed test(s): selftest_mptfo |
On Wed, 2022-09-21 at 14:55 +0200, Dmytro Shytyi wrote: > We use mptcp_gen_msk_ackseq_fasopen() > when we know this is the first chunk of data after MPTFO. > Without it I observe infinite retransmissions. The commit message should probably re-phrase to something more descriptive. With fastopen in place the first subflow socket is created before the MPC handshake completes, and we need to properly initialize the sequence numbers at MPC ACK reception. Thanks, Paolo
On 9/21/2022 8:02 PM, Paolo Abeni wrote: > With fastopen in place the first subflow socket is created > before the MPC handshake completes, and we need to properly initialize > the sequence numbers at MPC ACK reception. Thanks. FIxed locally, will be present in next v10 patch. Best, Dmytro
diff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c index 9ef49a2d2ea2..40c3fb8c75e3 100644 --- a/net/mptcp/fastopen.c +++ b/net/mptcp/fastopen.c @@ -30,3 +30,17 @@ int mptcp_setsockopt_sol_tcp_fastopen(struct mptcp_sock *msk, sockptr_t optval, return ret; } + +void mptcp_gen_msk_ackseq_fastopen(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow, + struct mptcp_options_received mp_opt) +{ + u64 ack_seq; + + WRITE_ONCE(msk->can_ack, true); + WRITE_ONCE(msk->remote_key, mp_opt.sndr_key); + mptcp_crypto_key_sha(msk->remote_key, NULL, &ack_seq); + ack_seq++; + WRITE_ONCE(msk->ack_seq, ack_seq); + pr_debug("ack_seq=%llu sndr_key=%llu", msk->ack_seq, mp_opt.sndr_key); + atomic64_set(&msk->rcv_wnd_sent, ack_seq); +} diff --git a/net/mptcp/options.c b/net/mptcp/options.c index 30d289044e71..0b6c4535750c 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -1208,6 +1208,11 @@ bool mptcp_incoming_options(struct sock *sk, struct sk_buff *skb) mpext->dsn64 = 1; mpext->mpc_map = 1; mpext->data_fin = 0; + + if (msk->is_mptfo) { + mptcp_gen_msk_ackseq_fastopen(msk, subflow, mp_opt); + mpext->data_seq = READ_ONCE(msk->ack_seq); + } } else { mpext->data_seq = mp_opt.data_seq; mpext->subflow_seq = mp_opt.subflow_seq; diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 57596cdfb1f9..b9e251848099 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -282,6 +282,7 @@ struct mptcp_sock { bool use_64bit_ack; /* Set when we received a 64-bit DSN */ bool csum_enabled; bool allow_infinite_fallback; + bool is_mptfo; u8 mpc_endpoint_id; u8 recvmsg_inq:1, cork:1, @@ -842,6 +843,8 @@ int mptcp_stream_connect(struct socket *sock, struct sockaddr *uaddr, int addr_l // Fast Open Mechanism functions begin int mptcp_setsockopt_sol_tcp_fastopen(struct mptcp_sock *msk, sockptr_t optval, unsigned int optlen); +void mptcp_gen_msk_ackseq_fastopen(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow, + struct mptcp_options_received mp_opt); // Fast Open Mechanism functions end static inline bool mptcp_pm_should_add_signal(struct mptcp_sock *msk)
We use mptcp_gen_msk_ackseq_fasopen() when we know this is the first chunk of data after MPTFO. Without it I observe infinite retransmissions. Signed-off-by: Dmytro Shytyi <dmytro@shytyi.net> --- net/mptcp/fastopen.c | 14 ++++++++++++++ net/mptcp/options.c | 5 +++++ net/mptcp/protocol.h | 3 +++ 3 files changed, 22 insertions(+)