| Message ID | 20240708180852.92919-1-kuniyu@amazon.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tcp: Make simultaneous connect() RFC-compliant. | expand |
On Mon, 8 Jul 2024 11:08:50 -0700 Kuniyuki Iwashima wrote:
> * Add patch 2
Hi Kuniyuki!
Looks like it also makes BPF CI fail. All of these:
https://netdev.bots.linux.dev/contest.html?branch=net-next-2024-07-09--15-00&executor=gh-bpf-ci&pw-n=0
But it builds down to the reuseport test on various platforms.
From: Jakub Kicinski <kuba@kernel.org> Date: Tue, 9 Jul 2024 12:52:09 -0700 > On Mon, 8 Jul 2024 11:08:50 -0700 Kuniyuki Iwashima wrote: > > * Add patch 2 > > Hi Kuniyuki! > > Looks like it also makes BPF CI fail. All of these: > https://netdev.bots.linux.dev/contest.html?branch=net-next-2024-07-09--15-00&executor=gh-bpf-ci&pw-n=0 > But it builds down to the reuseport test on various platforms. Oh, thanks for catching! It seems the test is using TFO, and somehow fastopen_rsk is cleared, but a packet is processed later in SYN_RECV state... Will look into it.
From: Kuniyuki Iwashima <kuniyu@amazon.com> Date: Tue, 9 Jul 2024 18:44:55 -0700 > From: Jakub Kicinski <kuba@kernel.org> > Date: Tue, 9 Jul 2024 12:52:09 -0700 > > On Mon, 8 Jul 2024 11:08:50 -0700 Kuniyuki Iwashima wrote: > > > * Add patch 2 > > > > Hi Kuniyuki! > > > > Looks like it also makes BPF CI fail. All of these: > > https://netdev.bots.linux.dev/contest.html?branch=net-next-2024-07-09--15-00&executor=gh-bpf-ci&pw-n=0 > > But it builds down to the reuseport test on various platforms. > > Oh, thanks for catching! > > It seems the test is using TFO, and somehow fastopen_rsk is cleared, > but a packet is processed later in SYN_RECV state... The test used MSG_FASTOPEN but TFO always failed due to lack of proper configuration, this should be fixed. IP 127.0.0.1.36477 > 127.0.0.1.53357: Flags [S], seq 2263448885:2263448893, win 65495, options [mss 65495,sackOK,TS val 2871616407 ecr 0,nop,wscale 7], length 8 IP 127.0.0.1.53357 > 127.0.0.1.36477: Flags [S.], seq 3767023264, ack 2263448886, win 65483, options [mss 65495,sackOK,TS val 2871616407 ecr 2871616407,nop,wscale 7], length 0 But this wasn't related, just red-herring. I just missed that the ACK of 3WHS was also processed by newly created SYN_RECV sk in tcp_rcv_state_process() called from tcp_child_process(). So, (sk->sk_state == TCP_SYN_RECV && !tp->fastopen_rsk) cannot deduce the cross SYN+ACK case. We need to use (sk->sk_state == TCP_SYN_RECV && sk->sk_socket). Will post v3. Thanks!
Patch 1 fixes an issue that BPF TCP option parser is triggered for ACK instead of SYN+ACK in the case of simultaneous connect(). Patch 2 removes an wrong assumption in tcp_ao/self-connnect tests. v2: * Target net-next and remove Fixes: tag * Don't skip bpf_skops_parse_hdr() to centralise sk_state check * Remove unnecessary ACK after SYN+ACK * Add patch 2 v1: https://lore.kernel.org/netdev/20240704035703.95065-1-kuniyu@amazon.com/ Kuniyuki Iwashima (2): tcp: Don't drop SYN+ACK for simultaneous connect(). selftests: tcp: Remove broken SNMP assumptions for TCP AO self-connect tests. net/ipv4/tcp_input.c | 9 +++++++++ .../selftests/net/tcp_ao/self-connect.c | 18 ------------------ 2 files changed, 9 insertions(+), 18 deletions(-)