Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > ->d_revalidate() often needs to access dentry parent and name; that has > to be done carefully, since the locking environment varies from caller > to caller. We are not guaranteed that dentry in question will not be > moved right under us - not unless the filesystem is such that nothing > on it ever gets renamed. > > It can be dealt with, but that results in boilerplate code that isn't > even needed - the callers normally have just found the dentry via dcache > lookup and want to verify that it's in the right place; they already > have the values of ->d_parent and ->d_name stable. There is a couple > of exceptions (overlayfs and, to less extent, ecryptfs), but for the > majority of calls that song and dance is not needed at all. > > It's easier to make ecryptfs and overlayfs find and pass those values if > there's a ->d_revalidate() instance to be called, rather than doing that > in the instances. > > This commit only changes the calling conventions; making use of supplied > values is left to followups. > > NOTE: some instances need more than just the parent - things like CIFS > may need to build an entire path from filesystem root, so they need > more precautions than the usual boilerplate. This series doesn't > do anything to that need - these filesystems have to keep their locking > mechanisms (rename_lock loops, use of dentry_path_raw(), private rwsem > a-la v9fs). > Reviewed-by: Gabriel Krisman Bertazi <gabriel@xxxxxxxxxx> Thanks for this. It is a requirement for the negative dentry patchset I sent a while ago that I'll revive now. -- Gabriel Krisman Bertazi
