Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: > On Wed, Jan 17, 2024 at 07:28:36PM -0300, Gabriel Krisman Bertazi wrote: > >> Note that, for strict mode, generic_ci_d_compare used to reject an >> invalid UTF-8 string, which would now be considered valid if it >> exact-matches the disk-name. But, if that is the case, the filesystem >> is corrupt. More than that, it really doesn't matter in practice, >> because the name-under-lookup will have already been rejected by >> generic_ci_d_hash and we won't even get here. > >> - if (ret >= 0) >> - return ret; >> - >> - if (sb_has_strict_encoding(sb)) >> + qstr.len = len; >> + qstr.name = str; >> + ret = utf8_strncasecmp(dentry->d_sb->s_encoding, name, &qstr); >> + if (ret < 0) >> return -EINVAL; > > Umm... So why bother with -EINVAL? The rest looks sane, but > considering the fact that your string *has* passed ->d_hash(), > do we need anything beyond > return utf8_strncasecmp(dentry->d_sb->s_encoding, name, &qstr); > here? No, you are right. In fact, it seems d_compare can't propagate errors anyway as it is only compared against 0, anyway. I spin the v2 dropping this bit as suggested. thanks, -- Gabriel Krisman Bertazi
