On Thu, 4 Jan 2024 at 11:09, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > My mistake was thinking that the dentry was attached more to the path than > the inode. But that doesn't seem to be the case. I wasn't sure if there was > a way to get to a dentry from the inode. Yeah, so dentry->inode and path->dentry are one-way translations, because the other way can have multiple different cases. IOW, a path will specify *one* dentry, and a dentry will specily *one* inode, but one inode can be associated with multiple dentries, and there may be other undiscovered dentries that *would* point to it but aren't even cached right now. And a single dentry can be part of multiple paths, thanks to bind mounts. The "inode->i_dentry" list is *not* a way to look up all dentries, because - as mentioned - there may be potential other paths (and thus other dentries) that lead to the same inode that just haven't been looked up yet (or that have already been aged out of the cache). Of course any *particular* filesystem may not have hard links (so one inode has only one possible dentry), and you may not have bind mounts, and it might be one of the virtual filesystems where everything is always in memory, so none of the above problems are guaranteed to be the case in any *particular* situation. But it's all part of why the dcache is actually really subtle. It's not just the RCU lookup rules and the specialized locking (both reflock and the rather complicated rules about d_lock ordering), it's also that whole "yeah, the filesystem only sees a 'dentry', but because of bind mounts the vfs layer actually does things internally in terms of 'struct path' in order to be able to then show that single fiolesystem in multiple places". Etc etc. There's a reason Al Viro ends up owning the dcache. Nobody else can wrap their tiny little minds around it all. Linus