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

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 29 Aug 2025 08:47:44 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> You don't even have to care about the unmap event, because that unmap
> - while it will potentially kill the lifetime of the hash if it was
> the last use of that file - also means that now there won't be any new
> stack traces with that hash any more. So you can ignore the lifetime
> in that respect: all that matters is that yes, it can get re-used, but
> you'll see a new mmap event with that hash if it is.

Basically what I need is that every time I add a file/hash mapping to the
hashtable, I really need a callback to know when that file goes away. And
then I can remove it from the hash table, so that the next time that hash is
added, it will trigger another "print the file associated with this hash".

It's OK to have the same hash for multiple files as long as it is traced.

All events have timestamps associated to them, so it is trivial to map
which hash mapping belongs to which stack trace.

The reason for the file_cache is to keep from having to do the lookup of
the file at every stack trace. But if I can have a callback for when that
vma gets changed, (as I'm assuming the file will last as long as the vma is
unmodified), then the callback could remove the hash value and this would
not be a problem.

My question now is, is there a callback that can be registered by the
file_cache to know when the vma or the file change?

-- Steve