From: Geliang Tang <geliang@kernel.org>
To: Jiayuan Chen <jiayuan.chen@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
Jakub Sitnicki <jakub@cloudflare.com>,
Eric Dumazet <edumazet@google.com>,
Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Sabrina Dubroca <sd@queasysnail.net>,
David Howells <dhowells@redhat.com>,
Matthieu Baerts <matttbe@kernel.org>,
Mat Martineau <martineau@kernel.org>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, mptcp@lists.linux.dev
Subject: Re: [PATCH bpf 1/2] bpf: drop duplicate check_app_limited in tcp_bpf_push
Date: Mon, 14 Sep 2026 18:06:38 +0800 [thread overview]
Message-ID: <095b530aa856a81d8576d235d28dcbc3e25841b2.camel@kernel.org> (raw)
In-Reply-To: <da26d2f3-7283-4e9f-85b4-6c12b9beda99@linux.dev>
Hi Jiayuan,
On Mon, 2026-09-14 at 16:24 +0800, Jiayuan Chen wrote:
>
> On 9/14/26 3:14 PM, Geliang Tang wrote:
> > From: Geliang Tang <tanggeliang@kylinos.cn>
> >
> > When the sendpage->MSG_SPLICE_PAGES migration series replaced
> > do_tcp_sendpages() with direct tcp_sendmsg_locked() calls, callers
> > that
> > had used do_tcp_sendpages() kept an explicit
> > tcp_rate_check_app_limited(sk)
> > that was originally needed to cover do_tcp_sendpages() (which did
> > not call
> > tcp_rate_check_app_limited()). After the inlining,
> > tcp_sendmsg_locked()
> > always provides the check, and the outer call became redundant.
> >
> > The site changed here, tcp_bpf_push(), is a MSG_SPLICE_PAGES loop
> > that
> > holds the socket lock and only iterates when size > 0;
> > tcp_sendmsg_locked()
> > is invoked on every iteration with state identical to what the
> > outer call
> > sees, so dropping the outer call is safe and behavior-preserving.
> >
> > A potential benefit of this change is that it facilitates future
> > reuse of
> > tcp_bpf_push() for sockmap support in protocols beyond TCP, such as
> > MPTCP.
> > Since tcp_rate_check_app_limited() is TCP-specific while
> > sendmsg_locked()
> > is a generic interface in struct proto_ops, this change allows us
> > to switch
> > to different protocols via sk->sk_socket->ops->sendmsg_locked()
> > without
> > carrying protocol-specific assumptions.
> >
> > Fixes: ebf2e8860eea ("tcp_bpf: Inline do_tcp_sendpages as it's now
> > a wrapper around tcp_sendmsg")
>
>
> Same as the tls one: this looks like a cleanup to me. Is there a real
> regression that affects kernel or user behavior?
>
> Do we really need a Fixes tag?
Thanks for the review. I fully agree - I'll drop the "Fixes" tags and
update the commit logs in v2.
Thanks,
-Geliang
>
>
> > Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> > ---
> > net/ipv4/tcp_bpf.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
> > index 2e234d155b5e..d5fcf3ce4861 100644
> > --- a/net/ipv4/tcp_bpf.c
> > +++ b/net/ipv4/tcp_bpf.c
> > @@ -108,7 +108,6 @@ static int tcp_bpf_push(struct sock *sk, struct
> > sk_msg *msg, u32 apply_bytes,
> > off = sge->offset;
> > page = sg_page(sge);
> >
> > - tcp_rate_check_app_limited(sk);
> > retry:
> > msghdr.msg_flags = flags | MSG_SPLICE_PAGES;
> > has_tx_ulp = tls_sw_has_ctx_tx(sk);
next prev parent reply other threads:[~2026-09-14 10:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 7:14 [PATCH 0/2] Drop redundant tcp_rate_check_app_limited calls Geliang Tang
2026-09-14 7:14 ` [PATCH bpf 1/2] bpf: drop duplicate check_app_limited in tcp_bpf_push Geliang Tang
2026-09-14 8:24 ` Jiayuan Chen
2026-09-14 8:45 ` gang.yan
2026-09-14 9:31 ` Matthieu Baerts
2026-09-14 8:45 ` gang.yan
2026-09-14 10:06 ` Geliang Tang [this message]
2026-09-14 7:14 ` [PATCH net 2/2] tls: drop duplicate check_app_limited in tls_push_sg Geliang Tang
2026-09-14 8:07 ` bot+bpf-ci
2026-09-15 23:01 ` [PATCH 0/2] Drop redundant tcp_rate_check_app_limited calls Jakub Kicinski
2026-09-16 10:30 ` Geliang Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=095b530aa856a81d8576d235d28dcbc3e25841b2.camel@kernel.org \
--to=geliang@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jakub@cloudflare.com \
--cc=jiayuan.chen@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox