From: Geliang Tang <tanggeliang@kylinos.cn>

These two patches drop the redundant tcp_rate_check_app_limited() calls
before tcp_sendmsg_locked() in tcp_bpf_push() and tls_push_sg(), since
tcp_rate_check_app_limited() is already called inside tcp_sendmsg_locked().

Note:

The first patch was originally part of my ongoing "MPTCP sockmap support"
series [1] (patch 5). Matthieu suggested converting it to a fix and sending
it directly to netdev. Removing the redundant tcp_rate_check_app_limited()
call benefits my subsequent MPTCP work: in patch 3 of that series, I
implement an MPTCP-specific mptcp_rate_check_app_limited() function and
call it in mptcp_sendmsg_locked(). This allows me to reuse tcp_bpf_push()
by simply replacing tcp_sendmsg_locked() with

		sk->sk_socket->ops->sendmsg_locked(),

without carrying protocol-specific assumptions.

The second patch similarly benefits my ongoing "MPTCP KTLS support" work
[2]. In patch 9 of that series, I had defined a check_app_limited()
interface in struct tls_prot_ops, but this interface is unnecessary if we
can reuse the existing TLS infrastructure more cleanly.

[1]
MPTCP sockmap support
https://lore.kernel.org/mptcp/b5f9e8d7-b738-1df6-3b5e-1d54cbbc663c@gmail.com/T/#t

[2]
MPTCP KTLS support
https://lore.kernel.org/netdev/cover.1782123118.git.tanggeliang@kylinos.cn/

Geliang Tang (2):
  bpf: drop duplicate check_app_limited in tcp_bpf_push
  tls: drop duplicate check_app_limited in tls_push_sg

 net/ipv4/tcp_bpf.c | 1 -
 net/tls/tls_main.c | 2 --
 2 files changed, 3 deletions(-)

-- 
2.53.0

On Mon, 14 Sep 2026 15:14:21 +0800 Geliang Tang wrote:
>   bpf: drop duplicate check_app_limited in tcp_bpf_push
>   tls: drop duplicate check_app_limited in tls_push_sg

you can't have 2 patches in one series targeting different trees

Hi Jakub,

On Tue, 2026-09-15 at 16:01 -0700, Jakub Kicinski wrote:
> On Mon, 14 Sep 2026 15:14:21 +0800 Geliang Tang wrote:
> >   bpf: drop duplicate check_app_limited in tcp_bpf_push
> >   tls: drop duplicate check_app_limited in tls_push_sg
> 
> you can't have 2 patches in one series targeting different trees

Right, my bad. I'll send them as two separate patches in v3, each to
its own tree.

Thanks,
-Geliang

Hi Geliang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Perf: Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/34818072039

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/0add685232c4
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1164231


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)