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] [day] [month] [year] [list]

Message-ID: <CAErzpmsC0qHL41KoRTxQ2-Xy=t74NnOZQxrv8VMFRSt3eoFrRA@mail.gmail.com>
Date: Fri, 6 Feb 2026 12:09:52 +0800
From: Donglin Peng <dolinux.peng@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, 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 Thu, Feb 5, 2026 at 11:56 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Thu, Feb 5, 2026 at 1:21 AM Donglin Peng <dolinux.peng@...il.com> wrote:
> >
> > On Wed, Feb 4, 2026 at 10:52 PM Donglin Peng <dolinux.peng@...il.com> wrote:
> > >
> > > On Wed, Feb 4, 2026 at 12:00 AM Alexei Starovoitov
> > > <alexei.starovoitov@...il.com> wrote:
> > > >
> > > > 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.
> > >
> > > Thanks, I agreed.
> > >
> > > >
> > > > 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 option is to print all matching entries, incurring increased
> > overhead and extended trace log length. However, I prefer printing
> > the first matching entry, though it might be inaccurate in rare cases.
>
> I disagree. It's not rare.
> I wouldn't print anything. Let user space deal with it.

Okay, I will implement this in libtraceevent first. By the way, would the first
patch [1] introducing the for_each_enumand for_each_enum64 helper
macros be acceptable?

[1] https://lore.kernel.org/lkml/20260202111548.3555306-2-dolinux.peng@gmail.com/