[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <874jlz69l2.fsf@suse.de>
Date: Wed, 19 Jul 2023 14:27:05 -0400
From: Gabriel Krisman Bertazi <krisman@...e.de>
To: Eric Biggers <ebiggers@...nel.org>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, tytso@....edu,
jaegeuk@...nel.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH v2 4/7] libfs: Support revalidation of encrypted
case-insensitive dentries
Eric Biggers <ebiggers@...nel.org> writes:
> Why would order matter? If either "feature" wants the dentry to be invalidated,
> then the dentry gets invalidated.
For instance, I was wondering makes sense for instance to memcmp d_name for
!DCACHE_NOKEY_NAME or if we wanted fscrypt_d_revalidate to come first.
>> Note we will start creating negative dentries in casefold directories after
>> patch 6/7, so unless we disable it here, we will start calling
>> fscrypt_d_revalidate for negative+casefold.
>
> fscrypt_d_revalidate() only cares about the DCACHE_NOKEY_NAME flag, so that's
> not a problem.
..I see now it is the first thing checked in fscrypt_d_revalidate.
>> Should I just drop this hunk? Unless you are confident it works as is, I
>> prefer to add this support in stages and keep negative dentries of
>> encrypted+casefold directories disabled for now.
>
> Unless I'm missing something, I think you're overcomplicating it.
Not overcomplicating. I'm just not familiar with fscrypt details enough to be
sure I could enable it. But yes, it seems safe.
> It should
> just work if you don't go out of your way to prohibit this case. I.e., just
> don't add the IS_ENCRYPTED(dir) check to generic_ci_d_revalidate().
I'll drop the check. And resend.
Thanks,
--
Gabriel Krisman Bertazi
Powered by blists - more mailing lists