> diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
[ ... ]
> +static int tcp_bpf_ioctl(struct sock *sk, int cmd, int *karg)
> +{
> + bool slow;
> +
> + /* we only care about FIONREAD */
> + if (cmd != SIOCINQ)
> + return tcp_ioctl(sk, cmd, karg);
> +
> + /* works similar as tcp_ioctl */
> + if (sk->sk_state == TCP_LISTEN)
> + return -EINVAL;
> +
> + slow = lock_sock_fast(sk);
> + *karg = sk_psock_msg_inq(sk);
> + unlock_sock_fast(sk, slow);
> +
> + return 0;
> +}
Can FIONREAD underreport available data here? The tcp_bpf_recvmsg()
function can read from both the BPF ingress_msg queue and the native TCP
receive queue:
if (!skb_queue_empty(&sk->sk_receive_queue) &&
sk_psock_queue_empty(psock)) {
sk_psock_put(sk, psock);
return tcp_recvmsg(sk, msg, len, flags, addr_len);
}
But tcp_bpf_ioctl() only returns the BPF queue size via sk_psock_msg_inq(),
ignoring any data in sk_receive_queue. For TCP_BPF_BASE sockets (sockmap
without verdict program), incoming data stays in the native receive queue.
If such a socket has data in sk_receive_queue but an empty ingress_msg,
FIONREAD would return 0 even though tcp_bpf_recvmsg() would successfully
read data.
Should this return the sum of both queues, similar to how the original
tcp_ioctl() uses tcp_inq()?
> diff --git a/net/ipv4/udp_bpf.c b/net/ipv4/udp_bpf.c
[ ... ]
> +static int udp_bpf_ioctl(struct sock *sk, int cmd, int *karg)
> +{
> + if (cmd != SIOCINQ)
> + return udp_ioctl(sk, cmd, karg);
> +
> + /* works similar as udp_ioctl. */
> + *karg = sk_msg_first_len(sk);
> + return 0;
> +}
Similar question for UDP: udp_bpf_recvmsg() checks psock_has_data() and
falls through to native udp recvmsg when the BPF queue is empty:
if (!psock_has_data(psock)) {
ret = sk_udp_recvmsg(sk, msg, len, flags, addr_len);
goto out;
}
If the BPF ingress_msg queue is empty but the native UDP receive queue has
a datagram, sk_msg_first_len() returns 0 while udp_bpf_recvmsg() would
successfully receive data. Should udp_bpf_ioctl() fall through to
udp_ioctl() when sk_msg_first_len() returns 0?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/20821477139
