From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: tytso@mit.edu, jaegeuk@kernel.org, linux-ext4@vger.kernel.org,
kernel@collabora.com
Subject: Re: [PATCH 3/5] ext4: Implement ci comparison using fscrypt_name
Date: Tue, 29 Mar 2022 12:11:04 -0400 [thread overview]
Message-ID: <87k0ccrb6v.fsf@collabora.com> (raw)
In-Reply-To: <YkJ4J0XNSkSSf2Xo@sol.localdomain> (Eric Biggers's message of "Mon, 28 Mar 2022 20:08:23 -0700")
Eric Biggers <ebiggers@kernel.org> writes:
> On Mon, Mar 21, 2022 at 11:00:02PM -0400, Gabriel Krisman Bertazi wrote:
>> By using fscrypt_name here, we can hide most of the caching casefold
>> logic from ext4. The condition in ext4_match is now quite redundant,
>> but this is addressed in the next patch.
>>
>> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
>> ---
>> fs/ext4/namei.c | 26 ++++++++++++--------------
>> include/linux/fscrypt.h | 4 ++++
>> 2 files changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
>> index 8976e5a28c73..71b4b05fae89 100644
>> --- a/fs/ext4/namei.c
>> +++ b/fs/ext4/namei.c
>> @@ -1321,10 +1321,9 @@ static void dx_insert_block(struct dx_frame *frame, u32 hash, ext4_lblk_t block)
>> /**
>> * ext4_ci_compare() - Match (case-insensitive) a name with a dirent.
>> * @parent: Inode of the parent of the dentry.
>> - * @name: name under lookup.
>> + * @fname: name under lookup.
>> * @de_name: Dirent name.
>> * @de_name_len: dirent name length.
>> - * @quick: whether @name is already casefolded.
>> *
>> * Test whether a case-insensitive directory entry matches the filename
>> * being searched. If quick is set, the @name being looked up is
>> @@ -1333,8 +1332,9 @@ static void dx_insert_block(struct dx_frame *frame, u32 hash, ext4_lblk_t block)
>> * Return: > 0 if the directory entry matches, 0 if it doesn't match, or
>> * < 0 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)
>> +static int ext4_ci_compare(const struct inode *parent,
>> + const struct fscrypt_name *fname,
>> + u8 *de_name, size_t de_name_len)
>> {
>> const struct super_block *sb = parent->i_sb;
>> const struct unicode_map *um = sb->s_encoding;
>> @@ -1357,10 +1357,10 @@ static int ext4_ci_compare(const struct inode *parent, const struct qstr *name,
>> entry.len = decrypted_name.len;
>> }
>>
>> - if (quick)
>> - ret = utf8_strncasecmp_folded(um, name, &entry);
>> + if (fname->cf_name.name)
>> + ret = utf8_strncasecmp_folded(um, &fname->cf_name, &entry);
>> else
>> - ret = utf8_strncasecmp(um, name, &entry);
>> + ret = utf8_strncasecmp(um, fname->usr_fname, &entry);
>>
>> if (!ret)
>> match = true;
>> @@ -1370,8 +1370,8 @@ static int ext4_ci_compare(const struct inode *parent, const struct qstr *name,
>> * the names have invalid characters.
>> */
>> ret = 0;
>> - match = ((name->len == entry.len) &&
>> - !memcmp(name->name, entry.name, entry.len));
>> + match = ((fname->usr_fname->len == entry.len) &&
>> + !memcmp(fname->usr_fname->name, entry.name, entry.len));
>> }
>>
>> out:
>> @@ -1440,6 +1440,8 @@ static bool ext4_match(struct inode *parent,
>> #endif
>>
>> #if IS_ENABLED(CONFIG_UNICODE)
>> + f.cf_name = fname->cf_name;
>> +
>> if (parent->i_sb->s_encoding && IS_CASEFOLDED(parent) &&
>> (!IS_ENCRYPTED(parent) || fscrypt_has_encryption_key(parent))) {
>> if (fname->cf_name.name) {
>> @@ -1451,13 +1453,9 @@ static bool ext4_match(struct inode *parent,
>> return false;
>> }
>> }
>> - ret = ext4_ci_compare(parent, &fname->cf_name, de->name,
>> - de->name_len, true);
>> - } else {
>> - ret = ext4_ci_compare(parent, fname->usr_fname,
>> - de->name, de->name_len, false);
>> }
>>
>> + ret = ext4_ci_compare(parent, &f, de->name, de->name_len);
>> if (ret < 0) {
>> /*
>> * Treat comparison errors as not a match. The
>> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
>> index 91ea9477e9bd..5dc4b3c805e4 100644
>> --- a/include/linux/fscrypt.h
>> +++ b/include/linux/fscrypt.h
>> @@ -36,6 +36,10 @@ struct fscrypt_name {
>> u32 minor_hash;
>> struct fscrypt_str crypto_buf;
>> bool is_nokey_name;
>> +
>> +#ifdef CONFIG_UNICODE
>> + struct qstr cf_name;
>> +#endif
>> };
>>
>
> This seems like the wrong approach. struct fscrypt_name shouldn't have fields
> that aren't used by the fs/crypto/ layer.
>
> Did you check what f2fs does? It has a struct f2fs_filename to represent
> everything f2fs needs to know about a filename, and it only uses
> struct fscrypt_name when communicating with the fs/crypto/ layer.
>
> struct ext4_filename already exists. Couldn't you use that here?
Hi Eric,
The reason I'm not using struct ext4_filename here is because I'm trying
to make this generic, so this function can be shared across filesystems
implementing casefold. Since the fscrypt_name abstraction is used for
case-sensitive comparison, I was trying to reuse that type for
case-insensitive as well. It seemed unnecessary to define a generic
casefold_name type just for passing the cf_name and disk_name to this
function, considering that fscrypt_name is already initialized by
ext4_match.
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2022-03-29 16:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 2:59 [PATCH 0/5] Clean up the case-insenstive lookup path Gabriel Krisman Bertazi
2022-03-22 3:00 ` [PATCH 1/5] ext4: Match the f2fs ci_compare implementation Gabriel Krisman Bertazi
2022-03-29 2:58 ` Eric Biggers
2022-03-22 3:00 ` [PATCH 2/5] ext4: Simplify the handling of chached insensitive names Gabriel Krisman Bertazi
2022-03-29 3:01 ` Eric Biggers
2022-03-22 3:00 ` [PATCH 3/5] ext4: Implement ci comparison using fscrypt_name Gabriel Krisman Bertazi
2022-03-29 3:08 ` Eric Biggers
2022-03-29 16:11 ` Gabriel Krisman Bertazi [this message]
2022-03-31 21:43 ` Eric Biggers
2022-04-04 19:59 ` Gabriel Krisman Bertazi
2022-03-22 3:00 ` [PATCH 4/5] ext4: Simplify hash check on ext4_match Gabriel Krisman Bertazi
2022-03-22 3:00 ` [PATCH 5/5] ext4: Log error when lookup of encoded dentry fails Gabriel Krisman Bertazi
2022-03-29 3:21 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k0ccrb6v.fsf@collabora.com \
--to=krisman@collabora.com \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=kernel@collabora.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.