On Tue, Aug 12, 2025 at 12:25:11PM +1000, NeilBrown wrote: > Proposed locking changes will require a dentry to remain hashed during > all directory operations which are currently protected by i_rwsem, or > for there to be a controlled transition from one hashed dentry to > another which maintains the lock - which will then be on the dentry. > > The current practice of dropping (unhashing) a dentry before calling > d_splice_alias() and d_add() defeats this need. > > This patch changes d_splice_alias() and d_add() to accept a hashed > dentry and to only drop it when necessary immediately before an > alternate dentry is hashed. These functions will, in a subsequent patch, > transfer the dentry locking across so that the name remains locked in > the directory.
The problem I have with that is the loss of information. That is to say, "is it hashed here" is hard to deduce from code. I would rather add d_splice_alias_hashed() and d_add_hashed(), and then see what's going on in specific callers. And yes, it requires analysis of places where we have d_drop()+d_add() - better have it done upfront than repeat it on every code audit *for* *each* *single* *call* *of* d_add(), including the ones that are currently obviously meant to be called for unhashed dentries. I realize that it's no fun at all - in particular, I'd never been able to get ceph folks to explain what is and what is not possible there. I would really hate to have that expand by order of magnitude - in effect, you make *all* calls of d_splice_alias() and d_add() similar mysteries.