Re: [PATCH bpf v2 14/15] bpf, sockmap: Keep the rest of the cork after a redirect

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue, Nov 03, 2026 at 01:38 PM netdev-bot+sashiko@kernel.org <netdev-bot+sashiko@kernel.org> wrote:
>>  			if (!cork)
>>  				*copied -= free;
>>  		}
>
> Should the cork case also subtract the freed bytes from *copied and keep
> the error?

No. That's deliberate, and the commit log says that it stays. See
commit fec51d40ea65 ("bpf: sockmap, zero sg_size on error when buffer is
released"). A cork has data of earlier sendmsg() calls. An error for
that data doesn't go to the current caller.

>> +		if (cork && msg->sg.size && !psock->cork) {
>
> Is this case meant to stay out of scope, or should *copied at least be
> reduced by the freed tail?

Out of scope. It's already explained in the commit log.
A smaller *copied alone is wrong. ret is 0 and tcp_bpf_sendmsg()
continues with the next bytes of the user buffer. Then the return value
doesn't tell which bytes are lost.

> This isn't a bug introduced by this patch, but putting the tail back here
> adds a new way into a race that already exists in the SK_PASS branch. Can
> a restored cork be freed while tcp_bpf_push() is still using it?

yeah. It's an old bug, not from this patch.
Each SK_PASS on a cork has this window, with or without a redirect
before it.

> Would it fix this to detach psock->cork in the SK_PASS branch before any
> push that can drop the lock, and attach it again under the lock afterwards,
> as the SK_REDIRECT branch does?

For this case, yes. Jiayuan proposed to serialize the senders in the
reply to patch 13. That covers this case and the new cork above.

> Non-cork messages already have the same accounting problem. Should
> sk_msg_apply_bytes() be charged with the bytes actually sent rather than
> tosend?

No. The verdict has to end before release_sock(). See
commit cd9733f5d75c ("tcp_bpf: Fix one concurrency problem in the
tcp_bpf_send_verdict function"). A refund after lock_sock() can land on
the verdict of another sender.
The prog runs again on the rest. Without this patch the kernel frees it.

> Could a test be added that checks how many bytes the peer receives?

Right. test_sockmap doesn't catch it. It can be a follow up.