| Message ID | 20220519014044.508099-5-krisman@collabora.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Clean up the case-insensitive lookup path | expand |
On Wed, May 18, 2022 at 09:40:40PM -0400, Gabriel Krisman Bertazi wrote: > Instead of reimplementing ext4_match_ci, use the new libfs helper. > > It should be fine to drop the fname->cf_name in the encrypted directory > case for the hash verification optimization because the only two ways > for fname->cf_name to be NULL on a case-insensitive lookup is > > (1) if name under lookup has an invalid encoding and the FS is not in > strict mode; or > > (2) if the directory is encrypted and we don't have the > key. > > For case (1), it doesn't matter, because the lookup hash will be > generated with fname->usr_name, the same as the disk (fallback to > invalid encoding behavior on !strict mode). Case (2) is caught by the > previous check (!IS_ENCRYPTED(parent) || > fscrypt_has_encryption_key(parent)), so we never reach this code. The code actually can be reached in case (2), because the key could have been added between ext4_fname_setup_ci_filename() and ext4_match(). I *think* your change doesn't make it any worse, since in such a case the name comparison is going to be comparing a no-key name to a regular one, which will very likely fail. So adding an additional way for the match to fail seems fine. It's hard to reason about, though. f2fs does things in a much cleaner way, as I've mentioned before, since it decides which type of match it wants at the beginning, when initializing struct f2fs_filename. - Eric
Eric Biggers <ebiggers@kernel.org> writes: > On Wed, May 18, 2022 at 09:40:40PM -0400, Gabriel Krisman Bertazi wrote: >> Instead of reimplementing ext4_match_ci, use the new libfs helper. >> >> It should be fine to drop the fname->cf_name in the encrypted directory >> case for the hash verification optimization because the only two ways >> for fname->cf_name to be NULL on a case-insensitive lookup is >> >> (1) if name under lookup has an invalid encoding and the FS is not in >> strict mode; or >> >> (2) if the directory is encrypted and we don't have the >> key. >> >> For case (1), it doesn't matter, because the lookup hash will be >> generated with fname->usr_name, the same as the disk (fallback to >> invalid encoding behavior on !strict mode). Case (2) is caught by the >> previous check (!IS_ENCRYPTED(parent) || >> fscrypt_has_encryption_key(parent)), so we never reach this code. > > The code actually can be reached in case (2), because the key could have been > added between ext4_fname_setup_ci_filename() and ext4_match(). Hm, I see! I didn't understand it would be possible to add a key during a lookup from your previous explanation, thanks for clarifying. > I *think* your change doesn't make it any worse, since in such a case the name > comparison is going to be comparing a no-key name to a regular one, which will > very likely fail. So adding an additional way for the match to fail > seems fine. Either way, no point in setting it for failure. I will restore the fname->cf_name != NULL check. > It's hard to reason about, though. f2fs does things in a much cleaner way, as > I've mentioned before, since it decides which type of match it wants at the > beginning, when initializing struct f2fs_filename. Yes, this is quite confusing. Are these implementation documented anywhere? Thank you for the review!
On Thu, May 19, 2022 at 03:52:10PM -0400, Gabriel Krisman Bertazi wrote: > > It's hard to reason about, though. f2fs does things in a much cleaner way, as > > I've mentioned before, since it decides which type of match it wants at the > > beginning, when initializing struct f2fs_filename. > > Yes, this is quite confusing. Are these implementation documented > anywhere? > Not very well. The f2fs implementation has some comments, though. E.g. see struct f2fs_filename and f2fs_setup_filename(). - Eric
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 206fcf8fdc16..98295b03a57c 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1318,58 +1318,6 @@ static void dx_insert_block(struct dx_frame *frame, u32 hash, ext4_lblk_t block) } #if IS_ENABLED(CONFIG_UNICODE) -/* - * Test whether a case-insensitive directory entry matches the filename - * being searched for. If quick is set, assume the name being looked up - * is already in the casefolded form. - * - * Returns: 0 if the directory entry matches, more than 0 if it - * doesn't match or less than zero on error. - */ -static int ext4_ci_compare(const struct inode *parent, const struct qstr *name, - u8 *de_name, size_t de_name_len, bool quick) -{ - const struct super_block *sb = parent->i_sb; - const struct unicode_map *um = sb->s_encoding; - struct fscrypt_str decrypted_name = FSTR_INIT(NULL, de_name_len); - struct qstr entry = QSTR_INIT(de_name, de_name_len); - int ret; - - if (IS_ENCRYPTED(parent)) { - const struct fscrypt_str encrypted_name = - FSTR_INIT(de_name, de_name_len); - - decrypted_name.name = kmalloc(de_name_len, GFP_KERNEL); - if (!decrypted_name.name) - return -ENOMEM; - ret = fscrypt_fname_disk_to_usr(parent, 0, 0, &encrypted_name, - &decrypted_name); - if (ret < 0) - goto out; - entry.name = decrypted_name.name; - entry.len = decrypted_name.len; - } - - if (quick) - ret = utf8_strncasecmp_folded(um, name, &entry); - else - ret = utf8_strncasecmp(um, name, &entry); - if (ret < 0) { - /* Handle invalid character sequence as either an error - * or as an opaque byte sequence. - */ - if (sb_has_strict_encoding(sb)) - ret = -EINVAL; - else if (name->len != entry.len) - ret = 1; - else - ret = !!memcmp(name->name, entry.name, entry.len); - } -out: - kfree(decrypted_name.name); - return ret; -} - int ext4_fname_setup_ci_filename(struct inode *dir, const struct qstr *iname, struct ext4_filename *name) { @@ -1432,20 +1380,25 @@ static bool ext4_match(struct inode *parent, #if IS_ENABLED(CONFIG_UNICODE) if (parent->i_sb->s_encoding && IS_CASEFOLDED(parent) && (!IS_ENCRYPTED(parent) || fscrypt_has_encryption_key(parent))) { - if (fname->cf_name.name) { - if (IS_ENCRYPTED(parent)) { - if (fname->hinfo.hash != EXT4_DIRENT_HASH(de) || - fname->hinfo.minor_hash != - EXT4_DIRENT_MINOR_HASH(de)) { + int ret; - return false; - } - } - return !ext4_ci_compare(parent, &fname->cf_name, - de->name, de->name_len, true); + if (IS_ENCRYPTED(parent) && + (fname->hinfo.hash != EXT4_DIRENT_HASH(de) || + fname->hinfo.minor_hash != EXT4_DIRENT_MINOR_HASH(de))) + return false; + + ret = generic_ci_match(parent, fname->usr_fname, + &fname->cf_name, de->name, + de->name_len); + if (ret < 0) { + /* + * Treat comparison errors as not a match. The + * only case where it happens is on a disk + * corruption or ENOMEM. + */ + return false; } - return !ext4_ci_compare(parent, fname->usr_fname, de->name, - de->name_len, false); + return ret; } #endif
Instead of reimplementing ext4_match_ci, use the new libfs helper. It should be fine to drop the fname->cf_name in the encrypted directory case for the hash verification optimization because the only two ways for fname->cf_name to be NULL on a case-insensitive lookup is (1) if name under lookup has an invalid encoding and the FS is not in strict mode; or (2) if the directory is encrypted and we don't have the key. For case (1), it doesn't matter, because the lookup hash will be generated with fname->usr_name, the same as the disk (fallback to invalid encoding behavior on !strict mode). Case (2) is caught by the previous check (!IS_ENCRYPTED(parent) || fscrypt_has_encryption_key(parent)), so we never reach this code. Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com> --- fs/ext4/namei.c | 81 +++++++++++-------------------------------------- 1 file changed, 17 insertions(+), 64 deletions(-)