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: <583E1D73-CED9-4526-A1DE-C65567EA779D@gmail.com>
Date: Thu, 28 Aug 2025 17:27:37 -0300
From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To: Steven Rostedt <rostedt@...nel.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>
CC: 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:17:18 PM GMT-03:00, Steven Rostedt <rostedt@...nel.org> wrote:
>On Thu, 28 Aug 2025 12:18:39 -0700
>Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>> On Thu, 28 Aug 2025 at 11:58, Arnaldo Carvalho de Melo
>> <arnaldo.melo@...il.com> wrote:
>> > >
>> > >Give the damn thing an actual filename or something *useful*, not a
>> > >number that user space can't even necessarily match up to anything.  
>> >
>> > A build ID?  
>> 
>> I think that's a better thing than the disgusting inode number, yes.
>
>I don't care what it is. I picked inode/device just because it was the
>only thing I saw available. I'm not sure build ID is appropriate either.
>
>> 
>> That said, I think they are problematic too, in that I don't think
>> they are universally available, so if you want to trace some
>> executable without build ids - and there are good reasons to do that -
>> you might hate being limited that way.
>> 
>> So I think you'd be much better off with just actual pathnames.
>
>As you mentioned below, the reason I avoided path names is that they
>take up too much of the ring buffer, and would be duplicated all over
>the place. I've run this for a while, and it only picked up a couple of
>hundred paths while the trace had several thousand stack traces.
>
>> 
>> Are there no trace events for "mmap this path"? Create a good u64 hash
>> from the contents of a 'struct path' (which is just two pointers: the
>> dentry and the mnt) when mmap'ing the file, and then you can just
>> associate the stack trace entry with that hash.
>
>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.

- Arnaldo 

 easily be switched over to
>do the same with a hash number.
>
>> 
>> That should be simple and straightforward, and hashing two pointers
>> should be simple and straightforward.
>
>Would a hash of these pointers have any collisions? That would be bad.
>
>Hmm, I just tried using the pointer to vma->vm_file->f_inode, and that
>gives me a unique number. Then I just need to map that back to the path name:
>
>       trace-cmd-1016    [002] ...1.    34.675646: inode_cache: inode=ffff8881007ed428 dev=[254:3] path=/usr/lib/x86_64-linux-gnu/libc.so.6
>       trace-cmd-1016    [002] ...1.    34.675893: inode_cache: inode=ffff88811970e648 dev=[254:3] path=/usr/local/lib64/libtracefs.so.1.8.2
>       trace-cmd-1016    [002] ...1.    34.675933: inode_cache: inode=ffff88811970b8f8 dev=[254:3] path=/usr/local/lib64/libtraceevent.so.1.8.4
>       trace-cmd-1016    [002] ...1.    34.675981: inode_cache: inode=ffff888110b78ba8 dev=[254:3] path=/usr/lib/x86_64-linux-gnu/libzstd.so.1.5.7
>            bash-1007    [003] ...1.    34.677316: inode_cache: inode=ffff888103f05d38 dev=[254:3] path=/usr/bin/bash
>            bash-1007    [003] ...1.    35.432951: inode_cache: inode=ffff888116be94b8 dev=[254:3] path=/usr/lib/x86_64-linux-gnu/libtinfo.so.6.5
>            bash-1018    [005] ...1.    36.104543: inode_cache: inode=ffff8881007e9dc8 dev=[254:3] path=/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
>            bash-1018    [005] ...1.    36.110407: inode_cache: inode=ffff888110b78298 dev=[254:3] path=/usr/lib/x86_64-linux-gnu/libz.so.1.3.1
>            bash-1018    [005] ...1.    36.110536: inode_cache: inode=ffff888103d09dc8 dev=[254:3] path=/usr/local/bin/trace-cmd
>
>I just swapped out the inode with the above (unsigned long)vma->vm_file->f_inode,
>and it appears to be unique.
>
>Thus, I could use that as the "hash" value and then the above could be turned into:
>
>       trace-cmd-1016    [002] ...1.    34.675646: inode_cache: hash=ffff8881007ed428 path=/usr/lib/x86_64-linux-gnu/libc.so.6
>       trace-cmd-1016    [002] ...1.    34.675893: inode_cache: hash=ffff88811970e648 path=/usr/local/lib64/libtracefs.so.1.8.2
>       trace-cmd-1016    [002] ...1.    34.675933: inode_cache: hash=ffff88811970b8f8 path=/usr/local/lib64/libtraceevent.so.1.8.4
>       trace-cmd-1016    [002] ...1.    34.675981: inode_cache: hash=ffff888110b78ba8 path=/usr/lib/x86_64-linux-gnu/libzstd.so.1.5.7
>            bash-1007    [003] ...1.    34.677316: inode_cache: hash=ffff888103f05d38 path=/usr/bin/bash
>            bash-1007    [003] ...1.    35.432951: inode_cache: hash=ffff888116be94b8 path=/usr/lib/x86_64-linux-gnu/libtinfo.so.6.5
>            bash-1018    [005] ...1.    36.104543: inode_cache: hash=ffff8881007e9dc8 path=/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
>            bash-1018    [005] ...1.    36.110407: inode_cache: hash=ffff888110b78298 path=/usr/lib/x86_64-linux-gnu/libz.so.1.3.1
>            bash-1018    [005] ...1.    36.110536: inode_cache: hash=ffff888103d09dc8 path=/usr/local/bin/trace-cmd
>
>This would mean the readers of the userstacktrace_delay need to also
>have this event enabled to do the mappings. But that shouldn't be an
>issue.
>
>-- Steve
>

- Arnaldo