From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 3/3] selftests/bpf: Add test for tracepoint btf_ids tracefs file
Date: Fri, 15 May 2026 21:09:44 +0100 [thread overview]
Message-ID: <8b2d626f-9fe2-47fc-830d-a26183913d77@gmail.com> (raw)
In-Reply-To: <20260515183659.31941C2BCB0@smtp.kernel.org>
On 5/15/26 7:36 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] Missing test environment check for `bpf_testmod` module causes spurious test failures.
> - [Medium] Out-of-bounds array reads and cascading failures due to non-aborting assertions and missing length checks.
> --
>
> commit 1c2fbe8e9b6c6c1082b4ae630c67ceb3b5db79b5
> Author: Mykyta Yatsenko <yatsenko@meta.com>
>
> selftests/bpf: Add test for tracepoint btf_ids tracefs file
>
> This commit adds a selftest to verify that the BTF IDs exposed in the
> tracefs btf_ids file for a module tracepoint match the expected FUNC_PROTO
> and STRUCT representations. It uses the bpf_testmod_test_read tracepoint
> to exercise the module/split-BTF path.
>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/tp_btf_ids.c b/tools/testing/selftests/bpf/prog_tests/tp_btf_ids.c
>> new file mode 100644
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/prog_tests/tp_btf_ids.c
>
> [ ... ]
>
>> +void test_tp_btf_ids(void)
>> +{
>> + const struct btf_type *proto_t, *rec_t;
>> + const struct btf_param *params;
>> + const struct btf_member *members;
>> + struct btf_ids_info info;
>> + struct btf *vmlinux_btf, *btf;
>> + const char *name;
>> + int err;
>> +
>
> Since this test relies on bpf_testmod_test_read from the bpf_testmod.ko
> kernel module, should there be a check for env.has_testmod here?
>
yes
> Without it, if the module is not loaded, the test might fail with a missing
> tracefs directory instead of gracefully skipping via test__skip().
>
>> + err = read_btf_ids(&info);
>> + if (!ASSERT_OK(err, "read btf_ids"))
>> + return;
>
> [ ... ]
>
>> + /*
>> + * raw_btf_id should be the FUNC_PROTO of __bpf_trace_<call>:
>> + * void *__data, struct task_struct *task,
>> + * struct bpf_testmod_test_read_ctx *ctx
>> + */
>> + proto_t = btf__type_by_id(btf, info.raw_id);
>> + if (!ASSERT_OK_PTR(proto_t, "raw type_by_id"))
>> + goto out;
>> + if (!ASSERT_TRUE(btf_is_func_proto(proto_t), "raw is FUNC_PROTO"))
>> + goto out;
>> + ASSERT_EQ(btf_vlen(proto_t), 3, "func_proto arg count");
>> +
>> + params = btf_params(proto_t);
>> + ASSERT_STREQ(param_name(btf, ¶ms[0]), "__data", "arg0 name");
>> + ASSERT_STREQ(param_name(btf, ¶ms[1]), "task", "arg1 name");
>> + ASSERT_STREQ(param_name(btf, ¶ms[2]), "ctx", "arg2 name");
>
> Does this code risk reading out of bounds if btf_vlen(proto_t) is less than 3?
>
> The ASSERT_EQ macro logs a failure but does not inherently abort the
> function execution. Should this be wrapped in a conditional check, such as
> if (!ASSERT_EQ(...)) goto out, to prevent accessing params[2] if the length
> is too small?
>
ok, I'll apply all these in v2
>> +
>> + /*
>> + * tp_btf_id should be STRUCT trace_event_raw_<call> with the
>> + * fields declared by TP_STRUCT__entry plus the common header.
>> + */
>> + rec_t = btf__type_by_id(btf, info.tp_id);
>> + if (!ASSERT_OK_PTR(rec_t, "tp type_by_id"))
>> + goto out;
>> + if (!ASSERT_TRUE(btf_is_struct(rec_t), "tp is STRUCT"))
>> + goto out;
>> + name = btf__name_by_offset(btf, rec_t->name_off);
>> + ASSERT_STREQ(name, "trace_event_raw_bpf_testmod_test_read",
>> + "tp struct name");
>> +
>> + members = btf_members(rec_t);
>> + ASSERT_STREQ(member_name(btf, &members[0]), "ent", "field0 name");
>> + ASSERT_STREQ(member_name(btf, &members[1]), "pid", "field1 name");
>> + ASSERT_STREQ(member_name(btf, &members[2]), "comm", "field2 name");
>> + ASSERT_STREQ(member_name(btf, &members[3]), "off", "field3 name");
>> + ASSERT_STREQ(member_name(btf, &members[4]), "len", "field4 name");
>
> Similarly, is it necessary to assert btf_vlen(rec_t) and conditionally jump
> to out if it is too small before accessing members[0] through members[4]?
>
> If the structure layout changes or is malformed, this might read adjacent
> BTF data.
>
>> +out:
>> + btf__free(btf);
>> + btf__free(vmlinux_btf);
>> +}
>
prev parent reply other threads:[~2026-05-15 20:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 16:41 [PATCH bpf-next 0/3] tracing: Expose tracepoint BTF ids via tracefs Mykyta Yatsenko
2026-05-15 16:41 ` [PATCH bpf-next 1/3] bpf: Export btf_get_module_btf() and btf_relocate_id() Mykyta Yatsenko
2026-05-15 17:56 ` sashiko-bot
2026-05-15 19:54 ` Mykyta Yatsenko
2026-05-15 16:41 ` [PATCH bpf-next 2/3] tracing: Expose tracepoint BTF ids via tracefs Mykyta Yatsenko
2026-05-15 18:25 ` sashiko-bot
2026-05-15 20:07 ` Mykyta Yatsenko
2026-05-15 22:48 ` Andrii Nakryiko
2026-05-15 16:41 ` [PATCH bpf-next 3/3] selftests/bpf: Add test for tracepoint btf_ids tracefs file Mykyta Yatsenko
2026-05-15 18:36 ` sashiko-bot
2026-05-15 20:09 ` Mykyta Yatsenko [this message]
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=8b2d626f-9fe2-47fc-830d-a26183913d77@gmail.com \
--to=mykyta.yatsenko5@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox