linux-kernel - Re: [PATCH 2/2] tracing: resolve enum names for function arguments via BTF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKXMzTsbrD8j0spJETXL77x=r30fEiPQLCiNr=XWtgB+Q@mail.gmail.com>
Date: Tue, 3 Feb 2026 08:00:45 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Donglin Peng <dolinux.peng@...il.com>, Andrii Nakryiko <andrii.nakryiko@...il.com>, 
	Alexei Starovoitov <ast@...nel.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Donglin Peng <pengdonglin@...omi.com>, 
	linux-trace-kernel <linux-trace-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>, 
	Eduard Zingerman <eddyz87@...il.com>
Subject: Re: [PATCH 2/2] tracing: resolve enum names for function arguments
 via BTF

On Tue, Feb 3, 2026 at 7:16 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue, 3 Feb 2026 21:50:47 +0800
> Donglin Peng <dolinux.peng@...il.com> wrote:
>
> > Testing revealed that sorting within resolve_btfids introduces issues with
> > btf__dedup. Therefore, I plan to move the sorting logic directly into
> > btf__add_enum_value and btf__add_enum64_value in libbpf, which are
> > invoked by pahole. However, it means that we need a newer pahole
> > version.
>
> Sorting isn't a requirement just something I wanted to bring up. If it's
> too complex and doesn't achieve much benefit then let's not do it.
>
> My worry is because "cat trace" takes quite a long time just reading the
> BTF arguments. I'm worried it will just get worse with enums as well.
>
> I have trace-cmd reading BTF now (just haven't officially released it) and
> doing an extract and reading the trace.dat file is much faster than reading
> the trace file with arguments. I'll need to implement the enum logic too in
> libtraceevent.

If you mean to do pretty printing of the trace in user space then +1 from me.

I don't like sorting enums either in resolve_btfid, pahole or kernel.
Sorted BTF by name was ok, since it doesn't change original semantics.
While sorting enums by value gets us to the grey zone where
the sequence of enum names in vmlinux.h becomes different than in dwarf.

Also id->name mapping in general is not precise.
There is no requirement for enums to be unique.
Just grabbing the first one:
ATA_PIO0 = 1,
ATA_PIO1 = 3,
ATA_PIO2 = 7,
ATA_UDMA0 = 1,
ATA_UDMA1 = 3,
ATA_UDMA2 = 7,
ATA_ID_CYLS = 1,
ATA_ID_HEADS = 3,
SCR_ERROR = 1,
SCR_CONTROL = 2,
SCR_ACTIVE = 3,

All these names are part of the same enum type.
Which one to print? First one?

another example:
enum {
        BPF_LOCAL_STORAGE_GET_F_CREATE = 1,
        BPF_SK_STORAGE_GET_F_CREATE = 1,
};

and another:
enum {
        BPF_SKB_TSTAMP_UNSPEC = 0,
        BPF_SKB_TSTAMP_DELIVERY_MONO = 1,
        BPF_SKB_CLOCK_REALTIME = 0,
        BPF_SKB_CLOCK_MONOTONIC = 1,
        BPF_SKB_CLOCK_TAI = 2,
};

I'd rather not print any and keep it integer only.

pw-bot: cr