On Wed, Jan 17, 2024 at 09:46:18PM -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. Can you make the code comment explain this, please? > + /* > + * Attempt a case-sensitive match first. It is cheaper and > + * should cover most lookups, including all the sane > + * applications that expect a case-sensitive filesystem. > + */ > + if (len == name->len && !memcmp(str, name->name, len)) > + return 0; Is the memcmp() safe, considering that the 'str' can be concurrently modified? The default dentry name comparison uses dentry_string_cmp(). Would using dentry_string_cmp() be a better choice here? - Eric
