From: sashiko-bot@kernel.org
To: "Amery Hung" <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 15/15] selftests/bpf: Add test for bpf_tcp_ops header option hooks
Date: Mon, 06 Jul 2026 17:47:20 +0000 [thread overview]
Message-ID: <20260706174721.14CE21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706171918.317102-16-ameryhung@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Multi-line comments in the new BPF selftest program do not follow the mandatory BPF subsystem comment style.
--
commit 0974a803b9e5fed2b4e8c0c5360735a19cae9901
Author: Amery Hung <ameryhung@gmail.com>
selftests/bpf: Add test for bpf_tcp_ops header option hooks
This commit adds a test for the bpf_tcp_ops header option hooks. It uses a
struct_ops program to reserve, store, and load an experimental TCP header
option to ensure the parse_hdr, hdr_opt_len, and write_hdr_opt callbacks
work together correctly.
> diff --git a/tools/testing/selftests/bpf/progs/bpf_tcp_ops_hdr.c b/tools/testing/selftests/bpf/progs/bpf_tcp_ops_hdr.c
> new file mode 100644
> index 0000000000000..46618a604d965
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/bpf_tcp_ops_hdr.c
[ ... ]
> +SEC("struct_ops")
> +void BPF_PROG(test_hdr_opt_len, struct sock *sk, struct sk_buff *skb,
> + struct request_sock *req, struct sk_buff *syn_skb,
> + enum tcp_synack_type synack_type, unsigned int *remaining)
> +{
> + hdr_opt_len_cnt++;
> +
> + /* Reserve TEST_OPT_LEN bytes; the helper decrements *remaining. Stacks
> + * with other progs in the cgroup hierarchy.
> + */
[Severity: Low]
This isn't a bug, but does this follow the BPF subsystem comment style?
Multi-line comments under BPF-related paths should have the opening /* on
its own line.
> + bpf_reserve_hdr_opt(ctx, TEST_OPT_LEN, 0);
> +}
> +
> +SEC("struct_ops")
> +void BPF_PROG(test_write_hdr_opt, struct sock *sk, struct sk_buff *skb,
> + struct request_sock *req, struct sk_buff *syn_skb,
> + enum tcp_synack_type synack_type, __u32 opt_off)
> +{
> + __u8 opt[TEST_OPT_LEN] = {
> + TEST_OPT_KIND, TEST_OPT_LEN, TEST_OPT_D0, TEST_OPT_D1,
> + };
> +
> + /* bpf_store_hdr_opt() takes the program ctx (the kernel reads the
> + * outgoing skb from it); it appends after any options already written
> + * in the reserved window, rejects duplicates, and confines the write to
> + * the header option scratch. Stacks across progs in the cgroup hierarchy.
> + */
[Severity: Low]
This is a similar style issue. Should the opening /* be placed on its own line
to match the required multi-line comment format?
> + if (bpf_store_hdr_opt(ctx, opt, sizeof(opt), 0))
> + return;
> +
> + write_cnt++;
> +}
> +
> +SEC("struct_ops")
> +void BPF_PROG(test_parse_hdr, struct sock *sk, struct sk_buff *skb)
> +{
> + __u8 opt[TEST_OPT_LEN] = {
> + TEST_OPT_KIND, TEST_OPT_LEN, TEST_OPT_D0, TEST_OPT_D1,
> + };
> +
> + parse_cnt++;
> +
> + /* Look up the experimental option written by test_write_hdr_opt() in
> + * the incoming skb. For an experimental kind the search matches on the
> + * 2-byte magic in opt[2..3]; on a match the found option is copied back
> + * into opt[].
> + */
[Severity: Low]
Here is another multi-line comment that starts on the same line as the opening
/*. Could this be reformatted to align with the modern BPF comment guidelines?
> + if (bpf_load_hdr_opt(ctx, opt, sizeof(opt), 0) < 0)
> + return;
> +
> + found_d0 = opt[2];
> + found_d1 = opt[3];
> + found_cnt++;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706171918.317102-1-ameryhung@gmail.com?part=15
next prev parent reply other threads:[~2026-07-06 17:47 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 17:19 [PATCH bpf-next v3 00/15] bpf: A common way to attach struct_ops to a cgroup Amery Hung
2026-07-06 17:19 ` [PATCH bpf-next v3 01/15] bpf: Remove __rcu tagging in st_link->map Amery Hung
2026-07-13 19:02 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 02/15] bpf: Make struct_ops tasks_rcu grace period optional Amery Hung
2026-07-06 17:44 ` sashiko-bot
2026-07-13 19:01 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 03/15] bpf: Add bpf_struct_ops accessor helpers Amery Hung
2026-07-06 17:34 ` sashiko-bot
2026-07-06 18:16 ` Amery Hung
2026-07-13 20:36 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 04/15] bpf: Remove unnecessary prog_list_prog() check Amery Hung
2026-07-13 20:35 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 05/15] bpf: Replace prog_list_prog() check with direct pl->prog and pl->link check Amery Hung
2026-07-13 21:27 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 06/15] bpf: Add prog_list_init_item(), prog_list_replace_item(), and prog_list_id() Amery Hung
2026-07-13 21:56 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 07/15] bpf: Move LSM trampoline unlink into bpf_cgroup_link_auto_detach() Amery Hung
2026-07-13 21:57 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 08/15] bpf: Add a few bpf_cgroup_array_* helper functions Amery Hung
2026-07-13 21:57 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 09/15] bpf: Add infrastructure to support attaching struct_ops to cgroups Amery Hung
2026-07-06 17:47 ` sashiko-bot
2026-07-14 6:21 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 10/15] bpf: Allow all struct_ops to use bpf_dynptr_from_skb() Amery Hung
2026-07-14 6:23 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 11/15] bpf: tcp: Support selected sock_ops callbacks as struct_ops Amery Hung
2026-07-06 18:28 ` bot+bpf-ci
2026-07-06 23:11 ` Amery Hung
2026-07-06 17:19 ` [PATCH bpf-next v3 12/15] bpf: tcp: Support parse/len/write header option hooks in bpf_tcp_ops Amery Hung
2026-07-06 17:45 ` sashiko-bot
2026-07-06 22:31 ` Amery Hung
2026-07-06 17:19 ` [PATCH bpf-next v3 13/15] libbpf: Support attaching struct_ops to a cgroup Amery Hung
2026-07-14 6:48 ` Emil Tsalapatis
2026-07-06 17:19 ` [PATCH bpf-next v3 14/15] selftests/bpf: Test " Amery Hung
2026-07-06 17:19 ` [PATCH bpf-next v3 15/15] selftests/bpf: Add test for bpf_tcp_ops header option hooks Amery Hung
2026-07-06 17:47 ` sashiko-bot [this message]
2026-07-06 18:18 ` Amery Hung
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=20260706174721.14CE21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=ameryhung@gmail.com \
--cc=bpf@vger.kernel.org \
--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.