Re: Squash-to: "selftests: mptcp: mptfo Initiator/Listener": Tests Results

Re: Squash-to: "selftests: mptcp: mptfo Initiator/Listener": Tests Results

[MPTCP CI]

Hi Paolo,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal:
  - Unstable: 1 failed test(s): mptcp_connect_mmap 🔴:
  - Task: https://cirrus-ci.com/task/5533446215303168
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5533446215303168/summary/summary.txt

- KVM Validation: debug:
  - Unstable: 1 failed test(s): mptcp_connect_mmap 🔴:
  - Task: https://cirrus-ci.com/task/6659346122145792
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/6659346122145792/summary/summary.txt

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/d2547fcc926f


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-debug

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 (Tessares)

[PATCH mptcp-next 0/5] mptcp: uniform code style and fix checkpatch splats

[Matthieu Baerts]

Just some small quick fixes about "issues" I saw when I applied the patches last
week. Nothing important: function names, place in the .h and small checkpatch
splats.

Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Dmytro Shytyi <dmytro@shytyi.net>

Matthieu Baerts (5):
  Squash-to: "mptcp: implement delayed seq generation for passive
    fastopen"
  Squash-to (part 1): "mptcp: add subflow_v(4,6)_send_synack()"
  Squash-to (part 2): "mptcp: add subflow_v(4,6)_send_synack()"
  Squash-to (part 3): "mptcp: add subflow_v(4,6)_send_synack()"
  Squash-to: "selftests: mptcp: mptfo Initiator/Listener"

 net/mptcp/fastopen.c                              | 8 ++++----
 net/mptcp/protocol.h                              | 8 ++++----
 net/mptcp/subflow.c                               | 6 +++---
 tools/testing/selftests/net/mptcp/mptcp_connect.c | 1 -
 4 files changed, 11 insertions(+), 12 deletions(-)


base-commit: ff1606d98e1c56fd9f181210e5463528173e99c5
-- 
2.37.2

[PATCH mptcp-next 1/5] Squash-to: "mptcp: implement delayed seq generation for passive fastopen"

[Matthieu Baerts]

mptcp: fastopen: uniform function names

Functions are usually prefixed with mptcp_<filename>_(...), e.g.
mptcp_fastopen_(...). Do the same here with the new fastopen functions.

Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
 net/mptcp/fastopen.c | 2 +-
 net/mptcp/protocol.h | 2 +-
 net/mptcp/subflow.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c
index e1fe919c00c2..d3f1ce7b45ac 100644
--- a/net/mptcp/fastopen.c
+++ b/net/mptcp/fastopen.c
@@ -51,7 +51,7 @@ void subflow_fastopen_send_synack_set_params(struct mptcp_subflow_context *subfl
 	mptcp_data_unlock(sk);
 }
 
-void mptcp_gen_msk_ackseq_fastopen(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow,
+void mptcp_fastopen_gen_msk_ackseq(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow,
 				   const struct mptcp_options_received *mp_opt)
 {
 	struct sock *sk = (struct sock *)msk;
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 0f1e26e55c01..96a3386c908a 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -848,7 +848,7 @@ void mptcp_event_addr_announced(const struct sock *ssk, const struct mptcp_addr_
 void mptcp_event_addr_removed(const struct mptcp_sock *msk, u8 id);
 bool mptcp_userspace_pm_active(const struct mptcp_sock *msk);
 
-void mptcp_gen_msk_ackseq_fastopen(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow,
+void mptcp_fastopen_gen_msk_ackseq(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow,
 				   const struct mptcp_options_received *mp_opt);
 void mptcp_set_owner_r(struct sk_buff *skb, struct sock *sk);
 void subflow_fastopen_send_synack_set_params(struct mptcp_subflow_context *subflow,
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 9c6f6c9a1f9a..b613046fea11 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -687,7 +687,7 @@ void mptcp_subflow_fully_established(struct mptcp_subflow_context *subflow,
 	WRITE_ONCE(msk->fully_established, true);
 
 	if (subflow->is_mptfo)
-		mptcp_gen_msk_ackseq_fastopen(msk, subflow, mp_opt);
+		mptcp_fastopen_gen_msk_ackseq(msk, subflow, mp_opt);
 }
 
 static struct sock *subflow_syn_recv_sock(const struct sock *sk,
-- 
2.37.2

[PATCH mptcp-next 2/5] Squash-to (part 1): "mptcp: add subflow_v(4,6)_send_synack()"

[Matthieu Baerts]

mptcp: fastopen: uniform function names (part 2)

Functions are usually prefixed with mptcp_<filename>_(...), e.g.
mptcp_fastopen_(...). Do the same here with the new fastopen functions.

While at it, also remove the 'send' from the function name as we don't
send anything, we only prepare it for the send. Best to avoid
confusions.

Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
 net/mptcp/fastopen.c | 4 ++--
 net/mptcp/protocol.h | 4 ++--
 net/mptcp/subflow.c  | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c
index d3f1ce7b45ac..4a85e1110328 100644
--- a/net/mptcp/fastopen.c
+++ b/net/mptcp/fastopen.c
@@ -6,8 +6,8 @@
 
 #include "protocol.h"
 
-void subflow_fastopen_send_synack_set_params(struct mptcp_subflow_context *subflow,
-					     struct request_sock *req)
+void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subflow,
+					      struct request_sock *req)
 {
 	struct sock *ssk = subflow->tcp_sock;
 	struct sock *sk = subflow->conn;
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 96a3386c908a..ad204ef88bc3 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -851,8 +851,8 @@ bool mptcp_userspace_pm_active(const struct mptcp_sock *msk);
 void mptcp_fastopen_gen_msk_ackseq(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow,
 				   const struct mptcp_options_received *mp_opt);
 void mptcp_set_owner_r(struct sk_buff *skb, struct sock *sk);
-void subflow_fastopen_send_synack_set_params(struct mptcp_subflow_context *subflow,
-					     struct request_sock *req);
+void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subflow,
+					      struct request_sock *req);
 
 static inline bool mptcp_pm_should_add_signal(struct mptcp_sock *msk)
 {
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index b613046fea11..255023b78924 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -322,7 +322,7 @@ static int subflow_v4_send_synack(const struct sock *sk, struct dst_entry *dst,
 		ireq->tstamp_ok = 0;
 
 	if (synack_type == TCP_SYNACK_FASTOPEN)
-		subflow_fastopen_send_synack_set_params(subflow, req);
+		mptcp_fastopen_subflow_synack_set_params(subflow, req);
 
 	return tcp_request_sock_ipv4_ops.send_synack(sk, dst, fl, req, foc, synack_type, syn_skb);
 }
@@ -343,7 +343,7 @@ static int subflow_v6_send_synack(const struct sock *sk, struct dst_entry *dst,
 		ireq->tstamp_ok = 0;
 
 	if (synack_type == TCP_SYNACK_FASTOPEN)
-		subflow_fastopen_send_synack_set_params(subflow, req);
+		mptcp_fastopen_subflow_synack_set_params(subflow, req);
 
 	return tcp_request_sock_ipv6_ops.send_synack(sk, dst, fl, req, foc, synack_type, syn_skb);
 }
-- 
2.37.2

[PATCH mptcp-next 3/5] Squash-to (part 2): "mptcp: add subflow_v(4,6)_send_synack()"

[Matthieu Baerts]

mptcp: move mptcp_set_owner_r() signature with others from protocol.c

Because this function is not specific to fastopen functions.

I added it at the end of the list there because there is no real order.
Maybe we should order them differently to reduce conflicts in case of
backports? Anyway, that would not be don't in this patch.

Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
 net/mptcp/protocol.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index ad204ef88bc3..20c0cf9fe453 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -633,6 +633,7 @@ void mptcp_sock_graft(struct sock *sk, struct socket *parent);
 struct socket *__mptcp_nmpc_socket(const struct mptcp_sock *msk);
 bool __mptcp_close(struct sock *sk, long timeout);
 void mptcp_cancel_work(struct sock *sk);
+void mptcp_set_owner_r(struct sk_buff *skb, struct sock *sk);
 
 bool mptcp_addresses_equal(const struct mptcp_addr_info *a,
 			   const struct mptcp_addr_info *b, bool use_port);
@@ -850,7 +851,6 @@ bool mptcp_userspace_pm_active(const struct mptcp_sock *msk);
 
 void mptcp_fastopen_gen_msk_ackseq(struct mptcp_sock *msk, struct mptcp_subflow_context *subflow,
 				   const struct mptcp_options_received *mp_opt);
-void mptcp_set_owner_r(struct sk_buff *skb, struct sock *sk);
 void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subflow,
 					      struct request_sock *req);
 
-- 
2.37.2

[PATCH mptcp-next 4/5] Squash-to (part 3): "mptcp: add subflow_v(4,6)_send_synack()"

[Matthieu Baerts]

mptcp: fix warning reported by checkpatch (with --codespell):

  fastopen.c:30:  'belown' may be misspelled - perhaps 'belong'?

(while at it...)

Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
 net/mptcp/fastopen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c
index 4a85e1110328..a3ec92c1e1fe 100644
--- a/net/mptcp/fastopen.c
+++ b/net/mptcp/fastopen.c
@@ -27,7 +27,7 @@ void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subf
 	skb_ext_reset(skb);
 	skb_orphan(skb);
 
-	/* We copy the fastopen data, but that don't belown to the mptcp sequence
+	/* We copy the fastopen data, but that don't belong to the mptcp sequence
 	 * space, need to offset it in the subflow sequence, see mptcp_subflow_get_map_offset()
 	 */
 	tp->copied_seq += skb->len;
-- 
2.37.2

[PATCH mptcp-next 5/5] Squash-to: "selftests: mptcp: mptfo Initiator/Listener"

[Matthieu Baerts]

mptcp: fix warning reported by checkpatch:

  mptcp_connect.c:398:  Blank lines aren't necessary after an open brace '{'

(while at it...)

Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
 tools/testing/selftests/net/mptcp/mptcp_connect.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.c b/tools/testing/selftests/net/mptcp/mptcp_connect.c
index c8bd109c991f..8a8266957bc5 100644
--- a/tools/testing/selftests/net/mptcp/mptcp_connect.c
+++ b/tools/testing/selftests/net/mptcp/mptcp_connect.c
@@ -399,7 +399,6 @@ static int sock_connect_mptcp(const char * const remoteaddr,
 			close(sock);
 			sock = -1;
 		} else {
-
 			perror("connect()");
 			close(sock);
 			sock = -1;
-- 
2.37.2

Re: [PATCH mptcp-next 0/5] mptcp: uniform code style and fix checkpatch splats

[Matthieu Baerts]

Hello,

On 14/11/2022 17:45, Matthieu Baerts wrote:
> Just some small quick fixes about "issues" I saw when I applied the patches last
> week. Nothing important: function names, place in the .h and small checkpatch
> splats.

An additional thing to do is to update the commit message of the first
patch of the "TFO listener" series which is currently:

  mptcp: introduce MSG_FASTOPEN flag

  In the following patches we will analyse the MSG_FASTOPEN flag
  in the mptcp_sendmsg() and invoke the MPTFO.

Maybe by:

  mptcp: add MSG_FASTOPEN sendmsg flag support

  Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") from
  Paolo Abeni, all the infrastructure is now in place to support this
  flag.

  The remaining action to do is to allow it and treat it as a fastopen
  message to be able to access this:

    sendto(sockfd, ..., ..., MSG_FASTOPEN, ..., ...);

What do you think?

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Re: [PATCH mptcp-next 0/5] mptcp: uniform code style and fix checkpatch splats

[Paolo Abeni]

On Mon, 2022-11-14 at 17:58 +0100, Matthieu Baerts wrote:
> Hello,
> 
> On 14/11/2022 17:45, Matthieu Baerts wrote:
> > Just some small quick fixes about "issues" I saw when I applied the patches last
> > week. Nothing important: function names, place in the .h and small checkpatch
> > splats.
> 
> An additional thing to do is to update the commit message of the first
> patch of the "TFO listener" series which is currently:
> 
>   mptcp: introduce MSG_FASTOPEN flag
> 
>   In the following patches we will analyse the MSG_FASTOPEN flag
>   in the mptcp_sendmsg() and invoke the MPTFO.
> 
> Maybe by:
> 
>   mptcp: add MSG_FASTOPEN sendmsg flag support
> 
>   Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") from
>   Paolo Abeni, all the infrastructure is now in place to support this
>   flag.
> 
>   The remaining action to do is to allow it and treat it as a fastopen
>   message to be able to access this:
> 
>     sendto(sockfd, ..., ..., MSG_FASTOPEN, ..., ...);
> 
> What do you think?

Possibly something a little less verbose? Alike:

"""
mptcp: add MSG_FASTOPEN sendmsg flag support

Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") all the
infrastructure is now in place to support the MSG_FASTOPEN flag, we
just need to call into the fastopen path in mptcp_sendmsg()
"""

?

Re: [PATCH mptcp-next 0/5] mptcp: uniform code style and fix checkpatch splats

[Matthieu Baerts]

Hi Paolo,

On 14/11/2022 18:08, Paolo Abeni wrote:
> On Mon, 2022-11-14 at 17:58 +0100, Matthieu Baerts wrote:
>> Hello,
>>
>> On 14/11/2022 17:45, Matthieu Baerts wrote:
>>> Just some small quick fixes about "issues" I saw when I applied the patches last
>>> week. Nothing important: function names, place in the .h and small checkpatch
>>> splats.
>>
>> An additional thing to do is to update the commit message of the first
>> patch of the "TFO listener" series which is currently:
>>
>>   mptcp: introduce MSG_FASTOPEN flag
>>
>>   In the following patches we will analyse the MSG_FASTOPEN flag
>>   in the mptcp_sendmsg() and invoke the MPTFO.
>>
>> Maybe by:
>>
>>   mptcp: add MSG_FASTOPEN sendmsg flag support
>>
>>   Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") from
>>   Paolo Abeni, all the infrastructure is now in place to support this
>>   flag.
>>
>>   The remaining action to do is to allow it and treat it as a fastopen
>>   message to be able to access this:
>>
>>     sendto(sockfd, ..., ..., MSG_FASTOPEN, ..., ...);
>>
>> What do you think?
> 
> Possibly something a little less verbose? Alike:
> 
> """
> mptcp: add MSG_FASTOPEN sendmsg flag support
> 
> Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") all the
> infrastructure is now in place to support the MSG_FASTOPEN flag, we
> just need to call into the fastopen path in mptcp_sendmsg()
> """

I know you would prefer a version without your name :-)

Sure, it is good to me!

Is it OK for you if I do the modifications and apply the 5 other small
patches? (no hurry :) )

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Re: Squash-to: "selftests: mptcp: mptfo Initiator/Listener": Tests Results

[MPTCP CI]

Hi Matthieu,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal:
  - Success! ✅:
  - Task: https://cirrus-ci.com/task/5358371401367552
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/5358371401367552/summary/summary.txt

- KVM Validation: debug:
  - Unstable: 1 failed test(s): selftest_mptcp_connect 🔴:
  - Task: https://cirrus-ci.com/task/6505649375281152
  - Summary: https://api.cirrus-ci.com/v1/artifact/task/6505649375281152/summary/summary.txt

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/55019258a7ff


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-debug

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 (Tessares)

Re: [PATCH mptcp-next 0/5] mptcp: uniform code style and fix checkpatch splats

[Paolo Abeni]

On Mon, 2022-11-14 at 18:11 +0100, Matthieu Baerts wrote:
> Hi Paolo,
> 
> On 14/11/2022 18:08, Paolo Abeni wrote:
> > On Mon, 2022-11-14 at 17:58 +0100, Matthieu Baerts wrote:
> > > Hello,
> > > 
> > > On 14/11/2022 17:45, Matthieu Baerts wrote:
> > > > Just some small quick fixes about "issues" I saw when I applied the patches last
> > > > week. Nothing important: function names, place in the .h and small checkpatch
> > > > splats.
> > > 
> > > An additional thing to do is to update the commit message of the first
> > > patch of the "TFO listener" series which is currently:
> > > 
> > >   mptcp: introduce MSG_FASTOPEN flag
> > > 
> > >   In the following patches we will analyse the MSG_FASTOPEN flag
> > >   in the mptcp_sendmsg() and invoke the MPTFO.
> > > 
> > > Maybe by:
> > > 
> > >   mptcp: add MSG_FASTOPEN sendmsg flag support
> > > 
> > >   Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") from
> > >   Paolo Abeni, all the infrastructure is now in place to support this
> > >   flag.
> > > 
> > >   The remaining action to do is to allow it and treat it as a fastopen
> > >   message to be able to access this:
> > > 
> > >     sendto(sockfd, ..., ..., MSG_FASTOPEN, ..., ...);
> > > 
> > > What do you think?
> > 
> > Possibly something a little less verbose? Alike:
> > 
> > """
> > mptcp: add MSG_FASTOPEN sendmsg flag support
> > 
> > Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") all the
> > infrastructure is now in place to support the MSG_FASTOPEN flag, we
> > just need to call into the fastopen path in mptcp_sendmsg()
> > """
> 
> I know you would prefer a version without your name :-)
> 
> Sure, it is good to me!
> 
> Is it OK for you if I do the modifications and apply the 5 other small
> patches? (no hurry :) )

[browsers!] Sure, please go ahead. I have a couple of additional
fastopen follow-ups pending...

/P

Re: [PATCH mptcp-next 0/5] mptcp: uniform code style and fix checkpatch splats

[Matthieu Baerts]

Hi Paolo,

On 15/11/2022 16:22, Paolo Abeni wrote:
> On Mon, 2022-11-14 at 18:11 +0100, Matthieu Baerts wrote:
>> Hi Paolo,
>>
>> On 14/11/2022 18:08, Paolo Abeni wrote:
>>> On Mon, 2022-11-14 at 17:58 +0100, Matthieu Baerts wrote:
>>>> Hello,
>>>>
>>>> On 14/11/2022 17:45, Matthieu Baerts wrote:
>>>>> Just some small quick fixes about "issues" I saw when I applied the patches last
>>>>> week. Nothing important: function names, place in the .h and small checkpatch
>>>>> splats.
>>>>
>>>> An additional thing to do is to update the commit message of the first
>>>> patch of the "TFO listener" series which is currently:
>>>>
>>>>   mptcp: introduce MSG_FASTOPEN flag
>>>>
>>>>   In the following patches we will analyse the MSG_FASTOPEN flag
>>>>   in the mptcp_sendmsg() and invoke the MPTFO.
>>>>
>>>> Maybe by:
>>>>
>>>>   mptcp: add MSG_FASTOPEN sendmsg flag support
>>>>
>>>>   Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") from
>>>>   Paolo Abeni, all the infrastructure is now in place to support this
>>>>   flag.
>>>>
>>>>   The remaining action to do is to allow it and treat it as a fastopen
>>>>   message to be able to access this:
>>>>
>>>>     sendto(sockfd, ..., ..., MSG_FASTOPEN, ..., ...);
>>>>
>>>> What do you think?
>>>
>>> Possibly something a little less verbose? Alike:
>>>
>>> """
>>> mptcp: add MSG_FASTOPEN sendmsg flag support
>>>
>>> Since commit 54f1944ed6d2 ("mptcp: factor out mptcp_connect()") all the
>>> infrastructure is now in place to support the MSG_FASTOPEN flag, we
>>> just need to call into the fastopen path in mptcp_sendmsg()
>>> """
>>
>> I know you would prefer a version without your name :-)
>>
>> Sure, it is good to me!
>>
>> Is it OK for you if I do the modifications and apply the 5 other small
>> patches? (no hurry :) )
> 
> [browsers!]

We told you not to use IE6 anymore...

> Sure, please go ahead. I have a couple of additional
> fastopen follow-ups pending...

Thanks! I can apply now not to block you :)

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Re: [PATCH mptcp-next 0/5] mptcp: uniform code style and fix checkpatch splats

[Matthieu Baerts]

Hi Paolo,

On 15/11/2022 16:22, Paolo Abeni wrote:
> [browsers!] Sure, please go ahead. I have a couple of additional
> fastopen follow-ups pending...

Thank you for the review!

I just applied these patches in our tree:

- 30d542994e3b: "squashed" (with conflicts) patch 1/5 in "mptcp:
implement delayed seq generation for passive fastopen"
- da41e5fb2e69: conflict in t/mptcp-add-subflow_v-4-6-_send_synack
- 183032806905: "squashed" patch 2/5 in "mptcp: add
subflow_v(4,6)_send_synack()"
- 8e2de0e11c9c: "squashed" patch 3/5 in "mptcp: add
subflow_v(4,6)_send_synack()"
- 8e7208654410: "squashed" patch 4/5 in "mptcp: add
subflow_v(4,6)_send_synack()"
- a1456d147b4e: "squashed" patch 5/5 in "selftests: mptcp: mptfo
Initiator/Listener"
- Results: 90b37ad8479c..a3b1d1930a5c (export)

Tests are now in progress:

https://cirrus-ci.com/github/multipath-tcp/mptcp_net-next/export/20221115T154226

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net