linux-kernel - Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace

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: <F8A0C174-F51B-40A4-8DC5-C75B8706BE74@gmail.com>
Date: Thu, 28 Aug 2025 18:00:22 -0300
From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To: Steven Rostedt <rostedt@...nel.org>
CC: Linus Torvalds <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org, x86@...nel.org,
 Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Andrii Nakryiko <andrii@...nel.org>, Indu Bhagat <indu.bhagat@...cle.com>,
 "Jose E. Marchesi" <jemarch@....org>,
 Beau Belgrave <beaub@...ux.microsoft.com>, Jens Remus <jremus@...ux.ibm.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Florian Weimer <fweimer@...hat.com>, Sam James <sam@...too.org>,
 Kees Cook <kees@...nel.org>, Carlos O'Donell <codonell@...hat.com>
Subject: Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace

On August 28, 2025 5:51:39 PM GMT-03:00, Steven Rostedt <rostedt@...nel.org> wrote:
>On Thu, 28 Aug 2025 17:27:37 -0300
>Arnaldo Carvalho de Melo <arnaldo.melo@...il.com> wrote:
>
>> >I would love to have a hash to use. The next patch does the mapping
>> >of the inode numbers to their path name. It can  
>> 
>> The path name is a nice to have detail, but a content based hash is
>> what we want, no?
>> 
>> Tracing/profiling has to be about contents of files later used for
>> analysis, and filenames provide no guarantee about that.
>
>I could add the build id to the inode_cache as well (which I'll rename
>to file_cache).
>
>Thus, the user stack trace will just have the offset and a hash value
>that will be match the output of the file_cache event which will have
>the path name and a build id (if one exists).
>
>Would that work?

Probably.

This "if it is available" question is valid, but since 2016 it's is more of a "did developers disabled it explicitly?"

If my "googling" isn't wrong, GNU LD defaults to generating a build ID in ELF images since 2011 and clang's companion since 2016.

So making it even more available than what the BPF guys did long ago and perf piggybacked on at some point, by having it cached, on request?, in some 20 bytes alignment hole in task_struct that would be only used when profiling/tracing may be amenable.

- Arnaldo