BPF List
 help / color / mirror / Atom feed
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, &params[0]), "__data", "arg0 name");
>> +	ASSERT_STREQ(param_name(btf, &params[1]), "task", "arg1 name");
>> +	ASSERT_STREQ(param_name(btf, &params[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);
>> +}
> 


      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