All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "KaFai Wan" <kafai.wan@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 4/4] selftests/bpf: Verify bpf-tcp-cc rejects TCP_NODELAY
Date: Wed, 22 Apr 2026 16:43:03 +0000	[thread overview]
Message-ID: <20260422164303.F1CE3C2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <20260421155804.135786-5-kafai.wan@linux.dev>

Sashiko AI review found 2 potential issue(s):
- [Medium] Test logic allows vacuous passes if BPF callbacks are never executed.
- [Low] Type mismatch for `bpf_setsockopt` return value.
--

commit 8a4ced8128582d3995376457598fd25202c0468a
Author: KaFai Wan <kafai.wan@linux.dev>

selftests/bpf: Verify bpf-tcp-cc rejects TCP_NODELAY

This commit adds a bpf_tcp_ca selftest to verify that the TCP_NODELAY
restriction is properly enforced in bpf-tcp-cc. It updates bpf_cubic to
exercise the init() and cwnd_event_tx_start() callbacks, ensuring both
reject the option with -EOPNOTSUPP.

> diff --git a/tools/testing/selftests/bpf/progs/bpf_cubic.c b/tools/testing/selftests/bpf/progs/bpf_cubic.c
> index ce18a4db813fa..b941ab3ebad57 100644
> --- a/tools/testing/selftests/bpf/progs/bpf_cubic.c
> +++ b/tools/testing/selftests/bpf/progs/bpf_cubic.c

[ ... ]

> @@ -170,10 +171,17 @@ static void bictcp_hystart_reset(struct sock *sk)
>  	ca->sample_cnt = 0;
>  }
>  
> +bool nodelay_init_reject = true;
> +bool nodelay_cwnd_event_tx_start_reject = true;

Can this test pass vacuously? Since these boolean variables are statically
initialized to true and the callbacks update them using a bitwise AND, the
userspace assertions will pass even if the callbacks are never executed.

Would it be safer to add explicit execution counters (like the existing
bpf_cubic_acked_called) to ensure the callbacks actually run during the
test workload?

> +
>  SEC("struct_ops")
>  void BPF_PROG(bpf_cubic_init, struct sock *sk)
>  {
>  	struct bpf_bictcp *ca = inet_csk_ca(sk);
> +	int true_val = 1, ret;
> +
> +	ret = bpf_setsockopt(sk, SOL_TCP, TCP_NODELAY, &true_val, sizeof(true_val));

This isn't a bug since we only expect a small negative constant here, but
bpf_setsockopt() returns a long. Could assigning the return value to an int
cause unintended truncation issues in the future?

> +	nodelay_init_reject &= ret == -EOPNOTSUPP;
>  
>  	bictcp_reset(ca);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260421155804.135786-1-kafai.wan@linux.dev?part=4

  reply	other threads:[~2026-04-22 16:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 15:58 [PATCH bpf-next v4 0/4] bpf: Reject TCP_NODELAY in TCP header option KaFai Wan
2026-04-21 15:58 ` [PATCH bpf-next v4 1/4] bpf: Reject TCP_NODELAY in TCP header option callbacks KaFai Wan
2026-04-21 16:51   ` bot+bpf-ci
2026-04-21 23:53     ` KaFai Wan
2026-04-21 15:58 ` [PATCH bpf-next v4 2/4] bpf: Reject TCP_NODELAY in bpf-tcp-cc KaFai Wan
2026-04-22  5:05   ` Jiayuan Chen
2026-04-21 15:58 ` [PATCH bpf-next v4 3/4] selftests/bpf: Test TCP_NODELAY in TCP hdr opt callbacks KaFai Wan
2026-04-21 15:58 ` [PATCH bpf-next v4 4/4] selftests/bpf: Verify bpf-tcp-cc rejects TCP_NODELAY KaFai Wan
2026-04-22 16:43   ` sashiko-bot [this message]
2026-04-22 20:36 ` [PATCH bpf-next v4 0/4] bpf: Reject TCP_NODELAY in TCP header option patchwork-bot+netdevbpf

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=20260422164303.F1CE3C2BCAF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kafai.wan@linux.dev \
    --cc=sashiko@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.