All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: chia-yu.chang@nokia-bell-labs.com
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2 net-next 1/1] tcp: Replace min_tso_segs() with tso_segs() CC callback for TCP Prague
Date: Mon, 15 Jun 2026 07:19:02 +0000	[thread overview]
Message-ID: <20260615071903.2B0671F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260614071756.239686-1-chia-yu.chang@nokia-bell-labs.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] BPF programs can cause a kernel panic by passing `mss_now == 0` to the `bbr_tso_segs` kfunc, leading to a division by zero.
- [Medium] The `tcp_tso_autosize` function is not registered as a BPF kfunc, preventing BPF congestion control algorithms from reusing default TSO autosizing logic.
--

commit 39a9bf39a3860ba9dd1b2bed8669b97491df87c6
Author: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>

tcp: Replace min_tso_segs() with tso_segs() CC callback for TCP Prague

This patch replaces existing min_tso_segs() with tso_segs() CC callbak
for CC algorithm to provides explicit tso segment number of each data
burst and overrides tcp_tso_autosize().

> diff --git a/net/ipv4/tcp_bbr.c b/net/ipv4/tcp_bbr.c
> --- a/net/ipv4/tcp_bbr.c
> +++ b/net/ipv4/tcp_bbr.c
[ ... ]
> @@ -297,11 +297,19 @@ static void bbr_set_pacing_rate(struct sock *sk, u32 bw, int gain)
>  }
>  
>  /* override sysctl_tcp_min_tso_segs */
> -__bpf_kfunc static u32 bbr_min_tso_segs(struct sock *sk)
> +static u32 bbr_min_tso_segs(struct sock *sk)
>  {
>  	return READ_ONCE(sk->sk_pacing_rate) < (bbr_min_tso_rate >> 3) ? 1 : 2;
>  }
>  
> +__bpf_kfunc static u32 bbr_tso_segs(struct sock *sk, u32 mss_now)
> +{
> +	u32 min_tso;
> +
> +	min_tso = bbr_min_tso_segs(sk);
> +	return tcp_tso_autosize(sk, mss_now, min_tso);
> +}

[Severity: High]
Can a buggy BPF program trigger a divide-by-zero panic here?

Since bbr_tso_segs() is exposed as a BPF kfunc, the verifier does not
restrict the value ranges of scalar arguments like mss_now. If mss_now is 0,
it is passed directly to tcp_tso_autosize(), where it is used as a divisor:

tcp_tso_autosize()
    ...
    return max_t(u32, bytes / mss_now, min_tso_segs);

Does this need an explicit check for mss_now == 0 to prevent a local denial
of service?

> +
>  static u32 bbr_tso_segs_goal(struct sock *sk)
>  {
>  	struct tcp_sock *tp = tcp_sk(sk);
[ ... ]
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
[ ... ]
> @@ -2269,6 +2269,7 @@ static u32 tcp_tso_autosize(const struct sock *sk, unsigned int mss_now,
>  
>  	return max_t(u32, bytes / mss_now, min_tso_segs);
>  }
> +EXPORT_SYMBOL(tcp_tso_autosize);

[Severity: Medium]
Is there a way for out-of-tree BPF congestion controls to reuse the default
autosizing logic?

With the removal of min_tso_segs, BPF congestion control algorithms that
want a custom minimum TSO size must implement tso_segs and handle the
autosizing themselves. However, while tcp_tso_autosize() is exported to C
modules here, it does not appear to be registered as a BPF kfunc (e.g., via
BTF_KFUNCS_START).

Does this force BPF developers to either lose custom minimum TSO sizing
capabilities or duplicate the tcp_tso_autosize() logic within their BPF
programs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260614071756.239686-1-chia-yu.chang@nokia-bell-labs.com?part=1

  reply	other threads:[~2026-06-15  7:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-14  7:17 [PATCH v2 net-next 1/1] tcp: Replace min_tso_segs() with tso_segs() CC callback for TCP Prague chia-yu.chang
2026-06-15  7:19 ` sashiko-bot [this message]
2026-06-16  1:51 ` Jakub Kicinski
2026-06-16  2:17   ` Jakub Kicinski

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=20260615071903.2B0671F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=chia-yu.chang@nokia-bell-labs.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.