Re: [PATCH v2 07/20] Pass parent directory inode and expected name to ->d_revalidate()

[Gabriel Krisman Bertazi <gabriel@krisman.be>]

Al Viro <viro@zeniv.linux.org.uk> 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@krisman.be>

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