Files
linux/include/net
Jiayuan Chen 36b62df568 bpf: Fix wrong copied_seq calculation
'sk->copied_seq' was updated in the tcp_eat_skb() function when the action
of a BPF program was SK_REDIRECT. For other actions, like SK_PASS, the
update logic for 'sk->copied_seq' was moved to tcp_bpf_recvmsg_parser()
to ensure the accuracy of the 'fionread' feature.

It works for a single stream_verdict scenario, as it also modified
sk_data_ready->sk_psock_verdict_data_ready->tcp_read_skb
to remove updating 'sk->copied_seq'.

However, for programs where both stream_parser and stream_verdict are
active (strparser purpose), tcp_read_sock() was used instead of
tcp_read_skb() (sk_data_ready->strp_data_ready->tcp_read_sock).
tcp_read_sock() now still updates 'sk->copied_seq', leading to duplicate
updates.

In summary, for strparser + SK_PASS, copied_seq is redundantly calculated
in both tcp_read_sock() and tcp_bpf_recvmsg_parser().

The issue causes incorrect copied_seq calculations, which prevent
correct data reads from the recv() interface in user-land.

We do not want to add new proto_ops to implement a new version of
tcp_read_sock, as this would introduce code complexity [1].

We could have added noack and copied_seq to desc, and then called
ops->read_sock. However, unfortunately, other modules didn’t fully
initialize desc to zero. So, for now, we are directly calling
tcp_read_sock_noack() in tcp_bpf.c.

[1]: https://lore.kernel.org/bpf/20241218053408.437295-1-mrpre@163.com

Fixes: e5c6de5fa0 ("bpf, sockmap: Incorrectly handling copied_seq")
Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Jiayuan Chen <mrpre@163.com>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://patch.msgid.link/20250122100917.49845-3-mrpre@163.com
2025-01-29 13:32:23 -08:00
..
2024-10-08 15:33:49 -07:00
2024-12-09 14:44:59 -08:00
2024-08-26 09:37:23 -07:00
2024-01-02 12:41:16 +00:00
2025-01-20 12:16:04 -08:00
2024-06-25 11:10:18 +02:00
2025-01-06 15:57:01 -08:00
2022-08-09 22:14:02 -07:00
2025-01-16 13:04:58 -08:00
2024-05-08 10:35:09 +01:00
2024-08-26 09:37:23 -07:00
2024-12-09 14:44:59 -08:00
2024-11-13 18:49:50 -08:00
2024-08-26 09:37:23 -07:00
2023-11-02 09:31:02 +01:00
2024-05-07 01:35:55 +02:00
2024-08-26 09:37:23 -07:00
2021-10-15 11:33:08 +01:00
2024-02-28 11:19:41 +00:00
2023-04-22 01:39:41 +02:00
2024-12-16 18:13:44 -08:00
2024-12-09 14:44:59 -08:00
2024-12-06 17:43:08 -08:00
2021-10-13 09:40:46 -07:00
2024-08-26 09:37:23 -07:00
2024-08-12 17:23:57 -07:00
2024-12-09 14:44:59 -08:00
2024-08-12 17:50:34 -07:00
2024-04-01 10:49:28 +01:00
2023-07-14 20:39:30 -07:00
2024-08-26 09:37:23 -07:00
2024-08-26 09:37:23 -07:00
2024-05-30 18:29:38 -07:00
2024-05-30 18:29:38 -07:00
2023-10-04 11:49:20 -07:00
2025-01-29 13:32:08 -08:00
2025-01-29 13:32:23 -08:00
2024-07-08 14:07:31 -07:00
2024-05-09 20:25:55 -07:00
2023-07-28 14:07:59 -07:00
2022-12-12 15:04:39 -08:00
2023-09-14 16:16:36 +02:00
2024-08-26 09:37:23 -07:00