Re: [PATCH bpf 1/2] bpf, sockmap: Stop reporting EPIPE on zero-length skb redirect

[Eli Skeggs]

On Mon, Oct 26, 2026 at 09:59:00AM +0800, Jiayuan Chen wrote:
>
> On 10/26/26 7:41 AM, Eli Skeggs via B4 Relay wrote:
> > From: Eli Skeggs <kernel@xxxxxxxxxxxxx>
> >
> > Treat a return of 0 as success when there is no data to send, while
> > continuing to fail on a 0 return with residual bytes. The loop exits
> > without incident on an empty skb, and the skb gets cleaned up as usual.
> > On an ingress redirect, the empty message is still queued as before, but
> > the target socket no longer reports EPIPE.
>
> The target can't receive anything after that though. The empty msg sits
> at the head of psock->ingress_msg and nothing ever dequeues it:
>
> [...]
>
> So the user gets EOF on a socket whose peer never closed, and everything
> redirected to it after the FIN is lost. Without a verdict prog on the
> target it is worse, tcp_bpf_recvmsg() returns -EFAULT forever.
>
> Since this patch is already about the zero-length skb, can you handle
> the ingress side too? E.g. in sk_psock_skb_ingress(), don't queue an
> empty msg when len is 0 and the skb was redirected (skb->sk != sk). The
> self PASS case must keep its empty msg since is_next_msg_fin() depends
> on it.

Yep, thanks for pointing that out.

Alexei suggested skipping empty skbs in sk_psock_backlog():
https://lore.kernel.org/all/DMEE6SW3UE97.2DF11HBEBKYYI@xxxxxxxxx/

To your point, I think the critical difference between these approaches
happens when the sk's backlog queue is not empty and the socket's own
FIN (the self PASS FIN) gets queued. In that case, we rely on the empty
msg to correctly update copied_seq, and skipping it means the copied
sequence number ends up 1 behind rcv_nxt.

This path is already broken: when a socket's FIN gets queued behind
other skbs, the backlog reports the erroneous EPIPE just as in the
redirect case.

I do like the simplicity of skipping the empty skbs entirely. I don't
immediately see what the consequence is for copied_seq being behind in
this terminal state, but the approach that updates copied_seq does seem
strictly more correct.

Is that the right interpretation? Let me know what direction I should
take for v2.