Thread (63 messages) 63 messages, 7 authors, 2025-09-09

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

From: Arnaldo Carvalho de Melo <hidden>
Date: 2025-08-29 17:58:03
Also in: bpf, lkml


On August 29, 2025 2:13:33 PM GMT-03:00, Linus Torvalds [off-list ref] wrote:
On Fri, 29 Aug 2025 at 10:02, Steven Rostedt [off-list ref] wrote:
quoted
Note, the ring buffer can be mapped to user space. So anything written into
the buffer is already exposed.
Oh, good point. Yeah, that means that you have to do the hashing
immediately. Too bad. Because while 'vma->vm_file' is basically free
(since you have to access the vma for other reasons anyway), a good
hash isn't.

Can't we continue with that idea by using some VMA sequential number that don't expose anything critical to user space but allows us to match stack entries to mmap records?

Deferring the heavily lift to when needed is great.

- Arnaldo 
siphash is good and fast for being what it is, but it's not completely
free. It's something like 50 shift/xor pairs, and it obviously needs
to also access that secret hash value that is likely behind a cache
miss..

Still, I suspect it's the best we've got.

(If hashing is noticeable, it *might* be worth it to use
'siphash_1u32()' and only hash 32 bits of the pointers. That makes the
hashing slightly cheaper, and since the low bits of the pointer will
be zero anyway due to alignment, and the high bits don't have a lot of
information in them either, it doesn't actually remove much
information. You might get collissions if the two pointers are exactly
32 GB apart or whatever, but that sounds really really unlucky)

               Linus
- Arnaldo 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help