From: Eric Biggers <ebiggers@kernel.org>
To: Gabriel Krisman Bertazi <krisman@suse.de>
Cc: viro@zeniv.linux.org.uk, jaegeuk@kernel.org, tytso@mit.edu,
amir73il@gmail.com, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v5 04/12] fscrypt: Drop d_revalidate for valid dentries during lookup
Date: Tue, 30 Jan 2024 16:47:24 -0800 [thread overview]
Message-ID: <20240131004724.GC2020@sol.localdomain> (raw)
In-Reply-To: <20240129204330.32346-5-krisman@suse.de>
On Mon, Jan 29, 2024 at 05:43:22PM -0300, Gabriel Krisman Bertazi wrote:
> Unencrypted and encrypted-dentries where the key is available don't need
> to be revalidated with regards to fscrypt, since they don't go stale
> from under VFS and the key cannot be removed for the encrypted case
> without evicting the dentry. Mark them with d_set_always_valid, to
"d_set_always_valid" doesn't appear in the diff itself.
> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
> index 4aaf847955c0..a22997b9f35c 100644
> --- a/include/linux/fscrypt.h
> +++ b/include/linux/fscrypt.h
> @@ -942,11 +942,22 @@ static inline int fscrypt_prepare_rename(struct inode *old_dir,
> static inline void fscrypt_prepare_lookup_dentry(struct dentry *dentry,
> bool is_nokey_name)
> {
> - if (is_nokey_name) {
> - spin_lock(&dentry->d_lock);
> + spin_lock(&dentry->d_lock);
> +
> + if (is_nokey_name)
> dentry->d_flags |= DCACHE_NOKEY_NAME;
> - spin_unlock(&dentry->d_lock);
> + else if (dentry->d_flags & DCACHE_OP_REVALIDATE &&
> + dentry->d_op->d_revalidate == fscrypt_d_revalidate) {
> + /*
> + * Unencrypted dentries and encrypted dentries where the
> + * key is available are always valid from fscrypt
> + * perspective. Avoid the cost of calling
> + * fscrypt_d_revalidate unnecessarily.
> + */
> + dentry->d_flags &= ~DCACHE_OP_REVALIDATE;
> }
> +
> + spin_unlock(&dentry->d_lock);
This makes lookups in unencrypted directories start doing the
spin_lock/spin_unlock pair. Is that really necessary?
These changes also make the inline function fscrypt_prepare_lookup() very long
(when including the fscrypt_prepare_lookup_dentry() that's inlined into it).
The rule that I'm trying to follow is that to the extent that the fscrypt helper
functions are inlined, the inline part should be a fast path for unencrypted
directories. Encrypted directories should be handled out-of-line.
So looking at the original fscrypt_prepare_lookup():
static inline int fscrypt_prepare_lookup(struct inode *dir,
struct dentry *dentry,
struct fscrypt_name *fname)
{
if (IS_ENCRYPTED(dir))
return __fscrypt_prepare_lookup(dir, dentry, fname);
memset(fname, 0, sizeof(*fname));
fname->usr_fname = &dentry->d_name;
fname->disk_name.name = (unsigned char *)dentry->d_name.name;
fname->disk_name.len = dentry->d_name.len;
return 0;
}
If you could just add the DCACHE_OP_REVALIDATE clearing for dentries in
unencrypted directories just before the "return 0;", hopefully without the
spinlock, that would be good. Yes, that does mean that
__fscrypt_prepare_lookup() will have to handle it too, for the case of dentries
in encrypted directories, but that seems okay.
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Gabriel Krisman Bertazi <krisman@suse.de>
Cc: tytso@mit.edu, amir73il@gmail.com,
linux-f2fs-devel@lists.sourceforge.net, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, jaegeuk@kernel.org,
linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v5 04/12] fscrypt: Drop d_revalidate for valid dentries during lookup
Date: Tue, 30 Jan 2024 16:47:24 -0800 [thread overview]
Message-ID: <20240131004724.GC2020@sol.localdomain> (raw)
In-Reply-To: <20240129204330.32346-5-krisman@suse.de>
On Mon, Jan 29, 2024 at 05:43:22PM -0300, Gabriel Krisman Bertazi wrote:
> Unencrypted and encrypted-dentries where the key is available don't need
> to be revalidated with regards to fscrypt, since they don't go stale
> from under VFS and the key cannot be removed for the encrypted case
> without evicting the dentry. Mark them with d_set_always_valid, to
"d_set_always_valid" doesn't appear in the diff itself.
> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
> index 4aaf847955c0..a22997b9f35c 100644
> --- a/include/linux/fscrypt.h
> +++ b/include/linux/fscrypt.h
> @@ -942,11 +942,22 @@ static inline int fscrypt_prepare_rename(struct inode *old_dir,
> static inline void fscrypt_prepare_lookup_dentry(struct dentry *dentry,
> bool is_nokey_name)
> {
> - if (is_nokey_name) {
> - spin_lock(&dentry->d_lock);
> + spin_lock(&dentry->d_lock);
> +
> + if (is_nokey_name)
> dentry->d_flags |= DCACHE_NOKEY_NAME;
> - spin_unlock(&dentry->d_lock);
> + else if (dentry->d_flags & DCACHE_OP_REVALIDATE &&
> + dentry->d_op->d_revalidate == fscrypt_d_revalidate) {
> + /*
> + * Unencrypted dentries and encrypted dentries where the
> + * key is available are always valid from fscrypt
> + * perspective. Avoid the cost of calling
> + * fscrypt_d_revalidate unnecessarily.
> + */
> + dentry->d_flags &= ~DCACHE_OP_REVALIDATE;
> }
> +
> + spin_unlock(&dentry->d_lock);
This makes lookups in unencrypted directories start doing the
spin_lock/spin_unlock pair. Is that really necessary?
These changes also make the inline function fscrypt_prepare_lookup() very long
(when including the fscrypt_prepare_lookup_dentry() that's inlined into it).
The rule that I'm trying to follow is that to the extent that the fscrypt helper
functions are inlined, the inline part should be a fast path for unencrypted
directories. Encrypted directories should be handled out-of-line.
So looking at the original fscrypt_prepare_lookup():
static inline int fscrypt_prepare_lookup(struct inode *dir,
struct dentry *dentry,
struct fscrypt_name *fname)
{
if (IS_ENCRYPTED(dir))
return __fscrypt_prepare_lookup(dir, dentry, fname);
memset(fname, 0, sizeof(*fname));
fname->usr_fname = &dentry->d_name;
fname->disk_name.name = (unsigned char *)dentry->d_name.name;
fname->disk_name.len = dentry->d_name.len;
return 0;
}
If you could just add the DCACHE_OP_REVALIDATE clearing for dentries in
unencrypted directories just before the "return 0;", hopefully without the
spinlock, that would be good. Yes, that does mean that
__fscrypt_prepare_lookup() will have to handle it too, for the case of dentries
in encrypted directories, but that seems okay.
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2024-01-31 0:47 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 20:43 [PATCH v5 00/12] Set casefold/fscrypt dentry operations through sb->s_d_op Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 01/12] ovl: Reject mounting over case-insensitive directories Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-31 0:22 ` Eric Biggers
2024-01-31 0:22 ` [f2fs-dev] " Eric Biggers
2024-01-31 0:31 ` Gabriel Krisman Bertazi
2024-01-31 0:31 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 02/12] fscrypt: Factor out a helper to configure the lookup dentry Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-31 0:29 ` Eric Biggers
2024-01-31 0:29 ` [f2fs-dev] " Eric Biggers
2024-01-29 20:43 ` [PATCH v5 03/12] fscrypt: Call fscrypt_prepare_lookup_dentry on unencrypted dentries Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 04/12] fscrypt: Drop d_revalidate for valid dentries during lookup Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-31 0:47 ` Eric Biggers [this message]
2024-01-31 0:47 ` Eric Biggers
2024-01-31 18:35 ` Gabriel Krisman Bertazi
2024-01-31 18:35 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-02-01 3:24 ` Eric Biggers
2024-02-01 3:24 ` [f2fs-dev] " Eric Biggers
2024-02-02 14:50 ` Gabriel Krisman Bertazi
2024-02-02 14:50 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-02-09 14:03 ` Christian Brauner
2024-02-09 14:03 ` [f2fs-dev] " Christian Brauner
2024-02-09 14:46 ` Gabriel Krisman Bertazi
2024-02-09 14:46 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 05/12] fscrypt: Drop d_revalidate once the key is added Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 06/12] fscrypt: Ignore plaintext dentries during d_move Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-31 0:55 ` Eric Biggers
2024-01-31 0:55 ` [f2fs-dev] " Eric Biggers
2024-01-29 20:43 ` [PATCH v5 07/12] libfs: Merge encrypted_ci_dentry_ops and ci_dentry_ops Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-31 1:00 ` Eric Biggers
2024-01-31 1:00 ` [f2fs-dev] " Eric Biggers
2024-01-29 20:43 ` [PATCH v5 08/12] libfs: Add helper to choose dentry operations at mount-time Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 09/12] ext4: Configure dentry operations at dentry-creation time Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-02-02 15:56 ` Theodore Ts'o
2024-02-02 15:56 ` [f2fs-dev] " Theodore Ts'o
2024-01-29 20:43 ` [PATCH v5 10/12] f2fs: " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 11/12] ubifs: " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
2024-01-29 20:43 ` [PATCH v5 12/12] libfs: Drop generic_set_encrypted_ci_d_ops Gabriel Krisman Bertazi
2024-01-29 20:43 ` [f2fs-dev] " Gabriel Krisman Bertazi
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=20240131004724.GC2020@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=amir73il@gmail.com \
--cc=jaegeuk@kernel.org \
--cc=krisman@suse.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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.