Message ID | 20230422000310.1802-5-krisman@suse.de (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | Support negative dentries on case-insensitive ext4 and f2fs | expand |
On Fri, Apr 21, 2023 at 08:03:07PM -0400, Gabriel Krisman Bertazi wrote: > From: Gabriel Krisman Bertazi <krisman@collabora.com> > > Preserve the existing behavior for encrypted directories, by rejecting > negative dentries of encrypted+casefolded directories. This allows > generic_ci_d_revalidate to be used by filesystems with both features > enabled, as long as the directory is either casefolded or encrypted, but > not both at the same time. > > Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com> > --- > fs/libfs.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/fs/libfs.c b/fs/libfs.c > index f8881e29c5d5..0886044db593 100644 > --- a/fs/libfs.c > +++ b/fs/libfs.c > @@ -1478,6 +1478,9 @@ static inline int generic_ci_d_revalidate(struct dentry *dentry, > const struct inode *dir = READ_ONCE(parent->d_inode); > > if (dir && needs_casefold(dir)) { > + if (IS_ENCRYPTED(dir)) > + return 0; > + Why not allow negative dentries in case-insensitive encrypted directories? I can't think any reason why it wouldn't just work. - Eric
Eric Biggers <ebiggers@kernel.org> writes: > On Fri, Apr 21, 2023 at 08:03:07PM -0400, Gabriel Krisman Bertazi wrote: >> From: Gabriel Krisman Bertazi <krisman@collabora.com> >> >> Preserve the existing behavior for encrypted directories, by rejecting >> negative dentries of encrypted+casefolded directories. This allows >> generic_ci_d_revalidate to be used by filesystems with both features >> enabled, as long as the directory is either casefolded or encrypted, but >> not both at the same time. >> >> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com> >> --- >> fs/libfs.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/fs/libfs.c b/fs/libfs.c >> index f8881e29c5d5..0886044db593 100644 >> --- a/fs/libfs.c >> +++ b/fs/libfs.c >> @@ -1478,6 +1478,9 @@ static inline int generic_ci_d_revalidate(struct dentry *dentry, >> const struct inode *dir = READ_ONCE(parent->d_inode); >> >> if (dir && needs_casefold(dir)) { >> + if (IS_ENCRYPTED(dir)) >> + return 0; >> + > > Why not allow negative dentries in case-insensitive encrypted directories? > I can't think any reason why it wouldn't just work. TBH, I'm not familiar with the details of combined encrypted+casefold support to be confident it works. This patch preserves the current behavior of disabling them for encrypted+casefold directories. I suspect it might require extra work that I'm not focusing on this patchset. For instance, what should be the order of fscrypt_d_revalidate and the checks I'm adding here? 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. 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.
On Tue, Jul 18, 2023 at 03:34:13PM -0400, Gabriel Krisman Bertazi wrote: > Eric Biggers <ebiggers@kernel.org> writes: > > > On Fri, Apr 21, 2023 at 08:03:07PM -0400, Gabriel Krisman Bertazi wrote: > >> From: Gabriel Krisman Bertazi <krisman@collabora.com> > >> > >> Preserve the existing behavior for encrypted directories, by rejecting > >> negative dentries of encrypted+casefolded directories. This allows > >> generic_ci_d_revalidate to be used by filesystems with both features > >> enabled, as long as the directory is either casefolded or encrypted, but > >> not both at the same time. > >> > >> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com> > >> --- > >> fs/libfs.c | 8 ++++++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/fs/libfs.c b/fs/libfs.c > >> index f8881e29c5d5..0886044db593 100644 > >> --- a/fs/libfs.c > >> +++ b/fs/libfs.c > >> @@ -1478,6 +1478,9 @@ static inline int generic_ci_d_revalidate(struct dentry *dentry, > >> const struct inode *dir = READ_ONCE(parent->d_inode); > >> > >> if (dir && needs_casefold(dir)) { > >> + if (IS_ENCRYPTED(dir)) > >> + return 0; > >> + > > > > Why not allow negative dentries in case-insensitive encrypted directories? > > I can't think any reason why it wouldn't just work. > > TBH, I'm not familiar with the details of combined encrypted+casefold > support to be confident it works.This patch preserves the current > behavior of disabling them for encrypted+casefold directories. Not allowing that combination reduces the usefulness of this patchset. Note that Android's use of casefold is always combined with encryption. > I suspect it might require extra work that I'm not focusing on this > patchset. For instance, what should be the order of > fscrypt_d_revalidate and the checks I'm adding here? Why would order matter? If either "feature" wants the dentry to be invalidated, then the dentry gets invalidated. > 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. > > 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. 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(). - Eric
Eric Biggers <ebiggers@kernel.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,
diff --git a/fs/libfs.c b/fs/libfs.c index f8881e29c5d5..0886044db593 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -1478,6 +1478,9 @@ static inline int generic_ci_d_revalidate(struct dentry *dentry, const struct inode *dir = READ_ONCE(parent->d_inode); if (dir && needs_casefold(dir)) { + if (IS_ENCRYPTED(dir)) + return 0; + if (!d_is_casefold_lookup(dentry)) return 0; @@ -1497,7 +1500,8 @@ static inline int generic_ci_d_revalidate(struct dentry *dentry, } } } - return 1; + + return fscrypt_d_revalidate(dentry, flags); } static const struct dentry_operations generic_ci_dentry_ops = { @@ -1517,7 +1521,7 @@ static const struct dentry_operations generic_encrypted_dentry_ops = { static const struct dentry_operations generic_encrypted_ci_dentry_ops = { .d_hash = generic_ci_d_hash, .d_compare = generic_ci_d_compare, - .d_revalidate = fscrypt_d_revalidate, + .d_revalidate_name = generic_ci_d_revalidate, }; #endif