Re: [PATCH bpf v2 03/15] bpf, sockmap: Don't let an SK_PASS verdict cover the next message

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

On Tue, Nov 03, 2026 at 01:37 PM netdev-bot+sashiko@kernel.org <netdev-bot+sashiko@kernel.org> wrote:
>> +		if (!psock->apply_bytes)
>> +			psock->eval = __SK_NONE;
>
> When psock->apply_bytes is not 0, eval stays __SK_PASS during the push.
> The budget is still debited only after tcp_bpf_push() returns. Can a
> second sender on the same socket still get past the prog here?

Yes, as today. It's already explained in the commit log.

> But B's message is sized against the budget before A's in-flight bytes
> are removed from it. Would it be better to reserve the budget before the
> push? That means debiting tosend, and ending the verdict when the budget
> reaches 0, before calling tcp_bpf_push(), instead of subtracting after a
> failure.

No. That breaks the single sender. After -EAGAIN the verdict has to
cover the bytes that the push didn't send. A refund after the failed
push can land on B's verdict.

> The shared-cork problem with two PASS senders already existed. The kfree()
> variant used to need a third sender to end a byte-limited verdict. The
> early reset makes it reachable with only two senders.

yeah. It's an old bug, not from this patch.
Two senders are enough today too. B's first message goes out with A's
verdict, and the code after the switch resets eval. The prog runs on B's
second message. SK_REDIRECT frees the cork that A still pushes.
The log of patch 13 says that a cork is not safe for two senders.
Jiayuan proposed to serialize the senders in the reply to that patch.

> With the early reset, can sender A's bytes be charged against a verdict
> that another sender installed?

Not a bug. eval, apply_bytes and sk_redir belong to the socket, not to
a thread. B's verdict ends early and the prog runs again for the rest.