Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Jul 2023 22:40:14 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     Gabriel Krisman Bertazi <krisman@suse.de>
Cc:     viro@zeniv.linux.org.uk, brauner@kernel.org, tytso@mit.edu,
        jaegeuk@kernel.org, linux-fsdevel@vger.kernel.org,
        linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH v2 5/7] libfs: Merge encrypted_ci_dentry_ops and
 ci_dentry_ops
Message-ID: <20230714054014.GE913@sol.localdomain>
References: <20230422000310.1802-1-krisman@suse.de>
 <20230422000310.1802-6-krisman@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230422000310.1802-6-krisman@suse.de>
Precedence: bulk

On Fri, Apr 21, 2023 at 08:03:08PM -0400, Gabriel Krisman Bertazi wrote:
> From: Gabriel Krisman Bertazi <krisman@collabora.com>
> 
> Now that casefold needs d_revalidate and calls fscrypt_d_revalidate
> itself, generic_encrypt_ci_dentry_ops and generic_ci_dentry_ops are now
> equivalent.  Merge them together and simplify the setup code.
> 
> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
> ---
>  fs/libfs.c | 44 +++++++++++++-------------------------------
>  1 file changed, 13 insertions(+), 31 deletions(-)
> 
> diff --git a/fs/libfs.c b/fs/libfs.c
> index 0886044db593..348ec6130198 100644
> --- a/fs/libfs.c
> +++ b/fs/libfs.c
> @@ -1504,7 +1504,7 @@ static inline int generic_ci_d_revalidate(struct dentry *dentry,
>  	return fscrypt_d_revalidate(dentry, flags);
>  }
>  
> -static const struct dentry_operations generic_ci_dentry_ops = {
> +static const struct dentry_operations generic_encrypted_ci_dentry_ops = {
>  	.d_hash = generic_ci_d_hash,
>  	.d_compare = generic_ci_d_compare,
>  	.d_revalidate_name = generic_ci_d_revalidate,
> @@ -1517,26 +1517,20 @@ static const struct dentry_operations generic_encrypted_dentry_ops = {
>  };
>  #endif
>  
> -#if defined(CONFIG_FS_ENCRYPTION) && IS_ENABLED(CONFIG_UNICODE)
> -static const struct dentry_operations generic_encrypted_ci_dentry_ops = {
> -	.d_hash = generic_ci_d_hash,
> -	.d_compare = generic_ci_d_compare,
> -	.d_revalidate_name = generic_ci_d_revalidate,
> -};
> -#endif
> -
>  /**
>   * generic_set_encrypted_ci_d_ops - helper for setting d_ops for given dentry
>   * @dentry:	dentry to set ops on
>   *
> - * Casefolded directories need d_hash and d_compare set, so that the dentries
> - * contained in them are handled case-insensitively.  Note that these operations
> - * are needed on the parent directory rather than on the dentries in it, and
> - * while the casefolding flag can be toggled on and off on an empty directory,
> - * dentry_operations can't be changed later.  As a result, if the filesystem has
> - * casefolding support enabled at all, we have to give all dentries the
> - * casefolding operations even if their inode doesn't have the casefolding flag
> - * currently (and thus the casefolding ops would be no-ops for now).
> + * Casefolded directories need d_hash, d_compare and d_revalidate set, so
> + * that the dentries contained in them are handled case-insensitively,
> + * but implement support for fs_encryption.  Note that these operations

The part ", but implement support for fs_encryption" is confusing.  It would be
clearer with that deleted, since encryption is covered by the next paragraph.

> + * are needed on the parent directory rather than on the dentries in it,
> + * and while the casefolding flag can be toggled on and off on an empty
> + * directory, dentry_operations can't be changed later.  As a result, if
> + * the filesystem has casefolding support enabled at all, we have to
> + * give all dentries the casefolding operations even if their inode
> + * doesn't have the casefolding flag currently (and thus the casefolding
> + * ops would be no-ops for now).
>   *
>   * Encryption works differently in that the only dentry operation it needs is
>   * d_revalidate, which it only needs on dentries that have the no-key name flag.
>   * The no-key flag can't be set "later", so we don't have to worry about that.
>   *
>   * Finally, to maximize compatibility with overlayfs (which isn't compatible
>   * with certain dentry operations) and to avoid taking an unnecessary
>   * performance hit, we use custom dentry_operations for each possible
>   * combination rather than always installing all operations.

When I wrote the last paragraph, I think I had in mind "each possible
combination of features".  Now it's changing in meaning to "each possible
combination of operations".  Maybe replace it with that to make it clearer?

- Eric