On Fri, 29 Aug 2025 08:47:44 -0700 Linus Torvalds <[email protected]> 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
