[PATCH perf] perf: Fix btf_vlen() signedness errors

[PATCH perf] perf: Fix btf_vlen() signedness errors

[Alan Maguire]

Commit f7a6b9eaff3e6 ("bpf: Extend BTF UAPI vlen, kinds to use unused bits")

extended the return value for btf_vlen() to __u32, triggering
errors for cases where an int was used to store return value.
Fix these cases for perf as was done for other libbpf consumers.

Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
 tools/perf/builtin-trace.c | 6 +++---
 tools/perf/util/btf.c      | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 48615ddccd93..9903d79c4b77 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -964,7 +964,7 @@ static bool syscall_arg__strtoul_btf_enum(char *bf, size_t size, struct syscall_
 	struct btf *btf = arg->trace->btf;
 	struct btf_enum *be = btf_enum(bt);
 
-	for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
+	for (unsigned int i = 0; i < btf_vlen(bt); ++i, ++be) {
 		const char *name = btf__name_by_offset(btf, be->name_off);
 		int max_len = max(size, strlen(name));
 
@@ -1009,9 +1009,9 @@ static bool syscall_arg__strtoul_btf_type(char *bf, size_t size, struct syscall_
 static size_t btf_enum_scnprintf(const struct btf_type *type, struct btf *btf, char *bf, size_t size, int val)
 {
 	struct btf_enum *be = btf_enum(type);
-	const int nr_entries = btf_vlen(type);
+	const unsigned int nr_entries = btf_vlen(type);
 
-	for (int i = 0; i < nr_entries; ++i, ++be) {
+	for (unsigned int i = 0; i < nr_entries; ++i, ++be) {
 		if (be->val == val) {
 			return scnprintf(bf, size, "%s",
 					 btf__name_by_offset(btf, be->name_off));
diff --git a/tools/perf/util/btf.c b/tools/perf/util/btf.c
index bb163fe87767..1716b49d3568 100644
--- a/tools/perf/util/btf.c
+++ b/tools/perf/util/btf.c
@@ -14,7 +14,7 @@ const struct btf_member *__btf_type__find_member_by_name(struct btf *btf,
 {
 	const struct btf_type *t = btf__type_by_id(btf, type_id);
 	const struct btf_member *m;
-	int i;
+	unsigned int i;
 
 	for (i = 0, m = btf_members(t); i < btf_vlen(t); i++, m++) {
 		const char *current_member_name = btf__name_by_offset(btf, m->name_off);
-- 
2.47.3

Re: [PATCH perf] perf: Fix btf_vlen() signedness errors

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Silent truncation of BTF_INFO_VLEN in libbpf's btf_vlen()
--

commit c28608c8a13cb7af8bf42f5aaadf102bb452fc40
Author: Alan Maguire <alan.maguire@oracle.com>

perf: Fix btf_vlen() signedness errors

This commit updates perf to use unsigned int loop counters when
iterating up to btf_vlen(). This avoids signedness errors after commit
f7a6b9eaff3e6 extended the BTF UAPI vlen to use previously unused bits.

> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index 48615ddccd93a..9903d79c4b77a 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -964,7 +964,7 @@ static bool syscall_arg__strtoul_btf_enum(char *bf, size_t size, struct syscall_
>  	struct btf *btf = arg->trace->btf;
>  	struct btf_enum *be = btf_enum(bt);
>  
> -	for (int i = 0; i < btf_vlen(bt); ++i, ++be) {
> +	for (unsigned int i = 0; i < btf_vlen(bt); ++i, ++be) {

[Severity: Medium]
This is a pre-existing issue, but does the btf_vlen function still silently
truncate the newly extended length?

Looking at tools/lib/bpf/btf.h, it appears to be defined as:

static inline __u16 btf_vlen(const struct btf_type *t)
{
        return BTF_INFO_VLEN(t->info);
}

Since commit f7a6b9eaff3e6 extended the internal BTF_INFO_VLEN from 16 to
24 bits to support more than 65535 elements, won't returning __u16 here
truncate the upper 8 bits?

While updating the loop variables to unsigned int fixes the signedness
warnings in consumers, does the underlying library still need an update to
return __u32 and prevent truncation?

>  		const char *name = btf__name_by_offset(btf, be->name_off);
>  		int max_len = max(size, strlen(name));

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622103418.579115-1-alan.maguire@oracle.com?part=1

Re: [PATCH perf] perf: Fix btf_vlen() signedness errors

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On Mon, Jun 22, 2026 at 11:34:18AM +0100, Alan Maguire wrote:
> Commit f7a6b9eaff3e6 ("bpf: Extend BTF UAPI vlen, kinds to use unused bits")
> 
> extended the return value for btf_vlen() to __u32, triggering
> errors for cases where an int was used to store return value.
> Fix these cases for perf as was done for other libbpf consumers.

I already sent:

  https://lore.kernel.org/r/20260617130038.34534-1-broonie@kernel.org

which I have been using as a fixup since I originally reported the issue
since Linus' tree is broken, Arnaldo said he'd applied it to the
perf-tools-next branch but it has not yet appeared in Linus' tree (and
it looks like he forgot to push it so his copy isn't getting picked up
in the merge either, the last update was on the 15th).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: [PATCH perf] perf: Fix btf_vlen() signedness errors

[Arnaldo Melo]

On June 22, 2026 7:53:40 AM GMT-03:00, Mark Brown <broonie@kernel.org> wrote:
>On Mon, Jun 22, 2026 at 11:34:18AM +0100, Alan Maguire wrote:
>> Commit f7a6b9eaff3e6 ("bpf: Extend BTF UAPI vlen, kinds to use unused bits")
>> 
>> extended the return value for btf_vlen() to __u32, triggering
>> errors for cases where an int was used to store return value.
>> Fix these cases for perf as was done for other libbpf consumers.
>
>I already sent:
>
>  https://lore.kernel.org/r/20260617130038.34534-1-broonie@kernel.org
>
>which I have been using as a fixup since I originally reported the issue
>since Linus' tree is broken, Arnaldo said he'd applied it to the
>perf-tools-next branch but it has not yet appeared in Linus' tree (and
>it looks like he forgot to push it so his copy isn't getting picked up
>in the merge either, the last update was on the 15th).

Its here:

<https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=776bd9ac834556ab6ff6b7ef74b71ac53d37855e>

I think Alan's latest patch has one more hunk, I'll get that one in and then send the pull request to Linus today,

- Arnaldo

Re: [PATCH perf] perf: Fix btf_vlen() signedness errors

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Mon, Jun 22, 2026 at 08:09:33AM -0300, Arnaldo Melo wrote:
> On June 22, 2026 7:53:40 AM GMT-03:00, Mark Brown <broonie@kernel.org> wrote:

> >which I have been using as a fixup since I originally reported the issue
> >since Linus' tree is broken, Arnaldo said he'd applied it to the
> >perf-tools-next branch but it has not yet appeared in Linus' tree (and
> >it looks like he forgot to push it so his copy isn't getting picked up
> >in the merge either, the last update was on the 15th).

> Its here:

> <https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=776bd9ac834556ab6ff6b7ef74b71ac53d37855e>

Ah, so it is - I missed it because Ian's series was applied on top of it
and doesn't look at all like fixes so I stopped reading the log (should
it be in -next given the merge window?).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH perf] perf: Fix btf_vlen() signedness errors

[Arnaldo Melo]

On June 22, 2026 8:18:43 AM GMT-03:00, Mark Brown <broonie@kernel.org> wrote:
>On Mon, Jun 22, 2026 at 08:09:33AM -0300, Arnaldo Melo wrote:
>> On June 22, 2026 7:53:40 AM GMT-03:00, Mark Brown <broonie@kernel.org> wrote:
>
>> >which I have been using as a fixup since I originally reported the issue
>> >since Linus' tree is broken, Arnaldo said he'd applied it to the
>> >perf-tools-next branch but it has not yet appeared in Linus' tree (and
>> >it looks like he forgot to push it so his copy isn't getting picked up
>> >in the merge either, the last update was on the 15th).
>
>> Its here:
>
>> <https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=776bd9ac834556ab6ff6b7ef74b71ac53d37855e>
>
>Ah, so it is - I missed it because Ian's series was applied on top of it
>and doesn't look at all like fixes so I stopped reading the log (should
>it be in -next given the merge window?).

Ian's series? Yeah, I was unsure about having it in this merge window, it went thru many versions, but your question is a fair one, I'll move it to the next merge window and send only up to your fix (+ Alan's missing hunk),

- Arnaldo