Message-ID: <20250829123321.63c9f525@gandalf.local.home>
Date: Fri, 29 Aug 2025 12:33:21 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Steven Rostedt <rostedt@...nel.org>, Arnaldo Carvalho de Melo
 <arnaldo.melo@...il.com>, 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 Fri, 29 Aug 2025 09:07:58 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> The dentry pointer will typically stick around rather aggressively,
> and will likely remain the same when you delete a file and create
> another one with the same name, and the mnt pointer will stick around
> too, so the contents of 'struct path' will be the exact same for two
> completely different files across a delete/create event.

I'm not sure how often a trace would expand the event of running code,
deleting the code, recreating it, and running it again. But that means the
stack traces of the original code will be useless regardless. But at a
minimum, the recreating of the code should trigger another print, and this
would give it a different build-id (which I'm not recording as well as the
path).

> 
> So hashing the path is very likely to stay the same as long as the
> actual path stays the same, but would be fairly insensitive to the
> underlying data changing. People might not care, particularly with
> executables and libraries that simply don't get switched around much.
> 
> And, 'struct file *' will get reused randomly just based on memory
> allocation issues, but I wouldn't be surprised if a close/open
> sequence would get the same 'struct file *' pointer.
> 
> So these will all have various different 'value stays the same, but
> the underlying data changed' patterns. I really think that you should
> just treat the hash as a very random number, not assign it *any*
> meaning at trace collection time, and the more random the better.
> 
> And then do all the "figure it out" work in user space when *looking*
> at the traces. It might be a bit more work, and involve a bit more
> data, but I _think_ it should be very straightforward to just do a
> "what was the last mmap that had this hash"

I just realized that I'm using the rhashtable as an "does this hash exist".
I could get the content of the item that matches the hash and compare it to
what was used to create the hash in the first place. If there's a reference
counter or some other identifier I could use to know that the passed in vma
is the same as what is in the hash table, I can use this to know if the
hash needs to be updated with the new information or not.

-- Steve

Powered by blists - more mailing lists