Eric Biggers <[email protected]> writes: > On Wed, May 18, 2022 at 01:23:16PM -0400, Gabriel Krisman Bertazi wrote: >> Instead of reimplementing ext4_match_ci, use the new libfs helper. >> >> Signed-off-by: Gabriel Krisman Bertazi <[email protected]> >> --- > [...] >> 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; >> } > > This needs an explanation for why it's okay to remove > 'fname->cf_name.name != NULL' from the condition for doing the hash comparison > for an encrypted+casefolded directory entry.
Hi Eric, The reason is that 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. I'll add the above rationale to the commit message. -- Gabriel Krisman Bertazi _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
