From: sashiko-bot@kernel.org
To: "Kuniyuki Iwashima" <kuniyu@google.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v1 bpf-next 1/8] selftest: bpf: Use BPF_SOCK_OPS_ALL_CB_FLAGS + 1 for bad_cb_test_rv.
Date: Fri, 08 May 2026 19:02:26 +0000 [thread overview]
Message-ID: <20260508190227.AFAE9C2BD00@smtp.kernel.org> (raw)
In-Reply-To: <20260508073355.3916746-2-kuniyu@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Using `BPF_SOCK_OPS_ALL_CB_FLAGS + 1` to test invalid BPF callback flags creates brittle test logic that assumes contiguous bitmasks and breaks forward compatibility.
--
commit dfed6c2387074d0f6f7afb70b6bba777371f7267
Author: Kuniyuki Iwashima <kuniyu@google.com>
selftest: bpf: Use BPF_SOCK_OPS_ALL_CB_FLAGS + 1 for bad_cb_test_rv.
Once bpf_sock_ops_cb_flags_set() supports a new flag,
tcpbpf_user.c fails due to the hard-coded max value, 0x80.
> diff --git a/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c b/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c
> index 7e8fe1bad03f5..e4849d2a2956f 100644
> --- a/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c
> +++ b/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c
> @@ -26,7 +26,8 @@ static void verify_result(struct tcpbpf_globals *result)
> ASSERT_EQ(result->bytes_acked, 1002, "bytes_acked");
> ASSERT_EQ(result->data_segs_in, 1, "data_segs_in");
> ASSERT_EQ(result->data_segs_out, 1, "data_segs_out");
> - ASSERT_EQ(result->bad_cb_test_rv, 0x80, "bad_cb_test_rv");
> + ASSERT_EQ(result->bad_cb_test_rv, BPF_SOCK_OPS_ALL_CB_FLAGS + 1,
> + "bad_cb_test_rv");
Is BPF_SOCK_OPS_ALL_CB_FLAGS + 1 robust for forward compatibility?
When the test is compiled, BPF_SOCK_OPS_ALL_CB_FLAGS + 1 is evaluated to a
hardcoded value. If this compiled test runs on a future kernel where this value
is supported, the helper will successfully set the flag and return 0. The
userspace test would still expect the hardcoded remainder, causing it to fail.
Furthermore, this assumes contiguous bitmasks. If a flag is ever deprecated or
skipped, adding 1 could overlap with valid bits.
Would it be better to use a safely distant bit, such as 1 << 30, to guarantee
the flag remains unsupported and the test doesn't break in the future?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260508073355.3916746-1-kuniyu@google.com?part=1
next prev parent reply other threads:[~2026-05-08 19:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 7:33 [PATCH v1 bpf-next 0/8] bpf: Add SOCK_OPS hooks for TCP AutoLOWAT Kuniyuki Iwashima
2026-05-08 7:33 ` [PATCH v1 bpf-next 1/8] selftest: bpf: Use BPF_SOCK_OPS_ALL_CB_FLAGS + 1 for bad_cb_test_rv Kuniyuki Iwashima
2026-05-08 19:02 ` sashiko-bot [this message]
2026-05-08 20:21 ` Kuniyuki Iwashima
2026-05-08 7:33 ` [PATCH v1 bpf-next 2/8] bpf: tcp: Introduce BPF_SOCK_OPS_RCVLOWAT_CB Kuniyuki Iwashima
2026-05-08 19:17 ` sashiko-bot
2026-05-08 20:26 ` Kuniyuki Iwashima
2026-05-08 7:33 ` [PATCH v1 bpf-next 3/8] bpf: tcp: Support bpf_skb_load_bytes() for BPF_SOCK_OPS_RCVLOWAT_CB Kuniyuki Iwashima
2026-05-08 15:15 ` Stanislav Fomichev
2026-05-08 19:45 ` Kuniyuki Iwashima
2026-05-11 14:56 ` Stanislav Fomichev
2026-05-08 7:33 ` [PATCH v1 bpf-next 4/8] tcp: Split out __tcp_set_rcvlowat() Kuniyuki Iwashima
2026-05-08 7:33 ` [PATCH v1 bpf-next 5/8] bpf: tcp: Add kfunc to adjust sk->sk_rcvlowat Kuniyuki Iwashima
2026-05-11 12:34 ` Björn Töpel
2026-05-08 7:33 ` [PATCH v1 bpf-next 6/8] bpf: tcp: Factorise bpf_skops_established() Kuniyuki Iwashima
2026-05-08 7:33 ` [PATCH v1 bpf-next 7/8] bpf: tcp: Add SOCK_OPS rcvlowat hook Kuniyuki Iwashima
2026-05-08 10:37 ` Jiayuan Chen
2026-05-08 11:30 ` Kuniyuki Iwashima
2026-05-08 12:19 ` Jiayuan Chen
2026-05-08 15:28 ` Stanislav Fomichev
2026-05-08 20:05 ` Kuniyuki Iwashima
2026-05-11 14:55 ` Stanislav Fomichev
2026-05-08 21:46 ` sashiko-bot
2026-05-08 7:33 ` [PATCH v1 bpf-next 8/8] selftest: bpf: Add test for BPF_SOCK_OPS_RCVLOWAT_CB Kuniyuki Iwashima
2026-05-08 15:35 ` Stanislav Fomichev
2026-05-08 20:19 ` Kuniyuki Iwashima
2026-05-08 21:47 ` Stanislav Fomichev
2026-05-08 21:58 ` Kuniyuki Iwashima
2026-05-08 22:17 ` sashiko-bot
2026-05-08 22:47 ` Kuniyuki Iwashima
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=20260508190227.AFAE9C2BD00@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kuniyu@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox