Re: [PATCH bpf-next v3] bpf: drop duplicate check_app_limited in tcp_bpf_push

Hi Jiayuan,

On Mon, 2026-09-21 at 19:46 +0800, Jiayuan Chen wrote:

On 9/17/26 5:45 PM, bot+bpf-ci@kernel.org wrote:

quoted

quoted

bpf: drop duplicate check_app_limited in tcp_bpf_push

Before commit c5c37af6ecad9 ("tcp: Convert do_tcp_sendpages() to
use
MSG_SPLICE_PAGES"), do_tcp_sendpages() did not call
tcp_rate_check_app_limited() internally, so callers needed an
explicit
tcp_rate_check_app_limited() to cover it. That commit replaced
do_tcp_sendpages() with direct tcp_sendmsg_locked() calls, which
perform
the check on every path that queues data. The outer call became
redundant
but was left in place.

This isn't a bug, but would it be clearer to cite ebf2e8860eea
("tcp_bpf:
Inline do_tcp_sendpages as it's now a wrapper around tcp_sendmsg")
as the
commit that left the outer tcp_rate_check_app_limited() in
tcp_bpf_push(),
with c5c37af6ecad9 mentioned as the commit that moved the check
inside
do_tcp_sendpages()?

Looking at the git history, c5c37af6ecad9 only touched
net/ipv4/tcp.c and
turned do_tcp_sendpages() into a wrapper that calls
tcp_sendmsg_locked().
The direct tcp_sendmsg_locked() call in tcp_bpf_push() was
introduced by
ebf2e8860eea, which kept the outer tcp_rate_check_app_limited(sk)
while
inlining the wrapper.

CI is right. ebf2e8860eea should be accurate.

You're right, thanks for the careful review. ebf2e8860eea is indeed the
commit that inlined the wrapper and left the outer check in place.
Updated in v4.

Thanks,
-Geliang

quoted

---
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/35203307255