On Sat, Jul 3, 2021 at 10:52 AM Jakub Sitnicki <jakub@xxxxxxxxxxxxxx> wrote:
> When running with just the verdict prog attached, the -EIO error from
> sk_psock_verdict_apply is propagated up to tcp_read_sock. That is, it
> maps to 0 bytes used by recv_actor. sk_psock_verdict_recv in this case.
>
> tcp_read_sock, if 0 bytes were used = copied, won't sk_eat_skb. It stays
> on sk_receive_queue.
Are you sure?
When recv_actor() returns 0, the while loop breaks:
1661 used = recv_actor(desc, skb, offset, len);
1662 if (used <= 0) {
1663 if (!copied)
1664 copied = used;
1665 break;
then it calls sk_eat_skb() a few lines after the loop:
...
1690 sk_eat_skb(sk, skb);
>
> sk->sk_data_ready
> sk_psock_verdict_data_ready
> ->read_sock(..., sk_psock_verdict_recv)
> tcp_read_sock (used = copied = 0)
> sk_psock_verdict_recv -> ret = 0
> sk_psock_verdict_apply -> -EIO
> sk_psock_skb_redirect -> -EIO
>
> However, I think this gets us stuck. What if no more data gets queued,
> and sk_data_ready doesn't get called again?
I think it is dropped by sk_eat_skb() in TCP case and of course the
sender will retransmit it after detecting this loss. So from this point of
view, there is no difference between drops due to overlimit and drops
due to eBPF program policy.
Thanks.
