On Thu, Jan 25, 2024 at 05:20:56PM -0300, Gabriel Krisman Bertazi wrote:
> Eric Biggers <ebiggers@xxxxxxxxxx> writes:
>
> > On Fri, Jan 19, 2024 at 03:47:36PM -0300, Gabriel Krisman Bertazi wrote:
> >> /*
> >> * When d_splice_alias() moves a directory's no-key alias to its plaintext alias
> >> * as a result of the encryption key being added, DCACHE_NOKEY_NAME must be
> >> * cleared. Note that we don't have to support arbitrary moves of this flag
> >> * because fscrypt doesn't allow no-key names to be the source or target of a
> >> * rename().
> >> */
> >> static inline void fscrypt_handle_d_move(struct dentry *dentry)
> >> {
> >> dentry->d_flags &= ~DCACHE_NOKEY_NAME;
> >> +
> >> + /*
> >> + * Save the d_revalidate call cost during VFS operations. We
> >> + * can do it because, when the key is available, the dentry
> >> + * can't go stale and the key won't go away without eviction.
> >> + */
> >> + if (dentry->d_op && dentry->d_op->d_revalidate == fscrypt_d_revalidate)
> >> + dentry->d_flags &= ~DCACHE_OP_REVALIDATE;
> >> }
> >
> > Is there any way to optimize this further for the case where fscrypt is not
> > being used? This is called unconditionally from d_move(). I've generally been
> > trying to avoid things like this where the fscrypt support slows things down for
> > everyone even when they're not using the feature.
>
> The problem would be figuring out whether the filesystem has fscrypt
> enabled. I think we can rely on sb->s_cop always being set:
>
> if (sb->s_cop)
> fscrypt_handle_d_move(dentry);
>
> What do you think?
That's better, I just wonder if there's an even better way. Do you need to do
this for dentries that don't have DCACHE_NOKEY_NAME set? If not, it would be
more efficient to test for DCACHE_NOKEY_NAME before clearing the flags.
- Eric
