Eric Biggers <ebigg...@kernel.org> writes:
> On Thu, Jan 25, 2024 at 05:20:56PM -0300, Gabriel Krisman Bertazi wrote:
>> Eric Biggers <ebigg...@kernel.org> 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.
I like that. We don't need it for dentries without DCACHE_NOKEY_NAME,
because those dentries have the d_revalidate disabled at lookup-time.
I raced my v4 with your comment, but I'll spin a v5 folding in this
suggestion shortly.
--
Gabriel Krisman Bertazi
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
