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: Steven Rostedt <rostedt@goodmis.org>
Date: 2025-08-29 23:42:31
Also in: bpf, lkml

On Fri, 29 Aug 2025 19:09:35 -0400
Steven Rostedt [off-list ref] wrote:
quoted
NOTHING like that. You don't look at the hash. You don't "register"
it. You don't touch it in any way. You literally just use it as a
value, and user space will figure it out later. At event parsing time.  
I guess this is where I'm stuck. How does user space know what those hash
values mean? Where does it get the information from?
This is why I had the stored hash items in a "file_cache". It was the way
to know that a new vma is being used and needs an event to show it.
That is, this would likely be useful:

  vma = NULL;
  foreach addr in callchain
    if (!vma || addr not in range of vma)
      vma = vma_lookup(addr);
You already stated that the vma_lookup() and the hash algorithm is very
expensive, but they need to be done anyway. A simple hash lookup is quick
and would be lost in the noise.


   vma = NULL;
   hash = 0;
   foreach addr in callchain
     if (!vma || addr not in range of vma) {
       vma = vma_lookup(addr);
       hash = get_hash(vma);
     }
     callchain[i] = addr - offset;
     hash[i] = hash;


I had that get_hash(vma) have something like:


  u32 get_hash(vma) {
     unsigned long ptr = (unsigned long)vma->vm_file;
     u32 hash;

     /* Remove alignment */
     ptr >>= 3;
     hash = siphash_1u32((u32)ptr, &key);

     if (lookup_hash(hash))
        return hash; // already saved

     // The above is the most common case and is quick.
     // Especially compared to vma_lookup() and the hash algorithm

     /* Slow but only happens when a new vma is discovered */
     trigger_event_that_maps_hash_to_file_data(hash, vma);

     /* Doesn't happen again for this hash value */
     save_hash(hash);


This is also where I would have a callback from munmap() to remove the
vmas from this hash table because they are no longer around. And if a new
vma came around with the same vm_file address, it would not be found in the
hash table and would trigger the print again with the hash and the new file
it represents.

This "garbage" was how I implemented the way to let user space know what
the meaning of the hash values are.

Otherwise, we need something else to expose to user space what those hashes
mean. And that's where I don't know what you are expecting.

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