Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2025-08-29 17:02:30
Also in:
bpf, lkml
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2025-08-29 17:02:30
Also in:
bpf, lkml
On Fri, 29 Aug 2025 09:50:12 -0700 Linus Torvalds [off-list ref] wrote:
On Fri, 29 Aug 2025 at 09:42, Linus Torvalds [off-list ref] wrote:quoted
Just use the hash. Don't do anything to it. Don't mess with it.In fact, at actual stack trace time, don't even do the hashing. Just save the raw pointer value (but as a *value*, not as a pointer: we absolutely do *not* want people to think that the random value can be used as a 'struct file' *: it needs to be a plain unsigned long, not some kernel pointer). Then the hashing can happen when you expose those entries to user space (in the "print" stage). At that point you can do that hash = siphash_1u64(value, secret); thing. That will likely help I$ and D$ too, since you won't be accessing the secret hashing data randomly, but do it only at trace output time (presumably in a fairly tight loop at that point).
Note, the ring buffer can be mapped to user space. So anything written into the buffer is already exposed. The "at trace output time" is done by user space, not the kernel (except when using "trace" and "trace_pipe" files). -- Steve