All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Gabriel Krisman Bertazi <krisman@suse.de>
Cc: ebiggers@kernel.org, jaegeuk@kernel.org, tytso@mit.edu,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 8/8] fscrypt: Move d_revalidate configuration back into fscrypt
Date: Thu, 21 Dec 2023 07:39:40 +0000	[thread overview]
Message-ID: <20231221073940.GC1674809@ZenIV> (raw)
In-Reply-To: <20231215211608.6449-9-krisman@suse.de>

On Fri, Dec 15, 2023 at 04:16:08PM -0500, Gabriel Krisman Bertazi wrote:

> +static const struct dentry_operations fscrypt_dentry_ops = {
> +	.d_revalidate = fscrypt_d_revalidate,
> +};
> +
>  int __fscrypt_prepare_lookup(struct inode *dir, struct dentry *dentry,
>  			     struct fscrypt_name *fname)
>  {
> @@ -106,6 +110,10 @@ int __fscrypt_prepare_lookup(struct inode *dir, struct dentry *dentry,
>  		spin_lock(&dentry->d_lock);
>  		dentry->d_flags |= DCACHE_NOKEY_NAME;
>  		spin_unlock(&dentry->d_lock);
> +
> +		/* Give preference to the filesystem hooks, if any. */
> +		if (!dentry->d_op)
> +			d_set_d_op(dentry, &fscrypt_dentry_ops);
>  	}
>  	return err;

Hmm...  Could we simply set ->s_d_op to &fscrypt_dentry_ops in non-ci case
*AND* have __fscrypt_prepare_lookup() clear DCACHE_OP_REVALIDATE in case
when it's not setting DCACHE_NOKEY_NAME and ->d_op->d_revalidate is
equal to fscrypt_d_revalidate?  I mean,

	spin_lock(&dentry->d_lock);
        if (fname->is_nokey_name)
                dentry->d_flags |= DCACHE_NOKEY_NAME;
        else if (dentry->d_flags & DCACHE_OP_REVALIDATE &&
		 dentry->d_op->d_revalidate == fscrypt_d_revalidate)
		dentry->d_flags &= ~DCACHE_OP_REVALIDATE;
	spin_unlock(&dentry->d_lock);

here + always set ->s_d_op for ext4 and friends (conditional upon
the CONFIG_UNICODE).

No encryption - fine, you get ->is_nokey_name false from the very
beginning, DCACHE_OP_REVALIDATE is cleared and VFS won't ever call
->d_revalidate(); not even the first time.  

Yes, you pay minimal price in dentry_unlink_inode() when we hit
        if (dentry->d_op && dentry->d_op->d_iput)
and bugger off after the second fetch instead of the first one.
I would be quite surprised if it turns out to be measurable,
but if it is, we can always add DCACHE_OP_IPUT to flags.
Similar for ->d_op->d_release (called in the end of
__dentry_kill()).  Again, that only makes sense if we get
a measurable overhead from that.

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Gabriel Krisman Bertazi <krisman@suse.de>
Cc: tytso@mit.edu, linux-f2fs-devel@lists.sourceforge.net,
	ebiggers@kernel.org, linux-fsdevel@vger.kernel.org,
	jaegeuk@kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v2 8/8] fscrypt: Move d_revalidate configuration back into fscrypt
Date: Thu, 21 Dec 2023 07:39:40 +0000	[thread overview]
Message-ID: <20231221073940.GC1674809@ZenIV> (raw)
In-Reply-To: <20231215211608.6449-9-krisman@suse.de>

On Fri, Dec 15, 2023 at 04:16:08PM -0500, Gabriel Krisman Bertazi wrote:

> +static const struct dentry_operations fscrypt_dentry_ops = {
> +	.d_revalidate = fscrypt_d_revalidate,
> +};
> +
>  int __fscrypt_prepare_lookup(struct inode *dir, struct dentry *dentry,
>  			     struct fscrypt_name *fname)
>  {
> @@ -106,6 +110,10 @@ int __fscrypt_prepare_lookup(struct inode *dir, struct dentry *dentry,
>  		spin_lock(&dentry->d_lock);
>  		dentry->d_flags |= DCACHE_NOKEY_NAME;
>  		spin_unlock(&dentry->d_lock);
> +
> +		/* Give preference to the filesystem hooks, if any. */
> +		if (!dentry->d_op)
> +			d_set_d_op(dentry, &fscrypt_dentry_ops);
>  	}
>  	return err;

Hmm...  Could we simply set ->s_d_op to &fscrypt_dentry_ops in non-ci case
*AND* have __fscrypt_prepare_lookup() clear DCACHE_OP_REVALIDATE in case
when it's not setting DCACHE_NOKEY_NAME and ->d_op->d_revalidate is
equal to fscrypt_d_revalidate?  I mean,

	spin_lock(&dentry->d_lock);
        if (fname->is_nokey_name)
                dentry->d_flags |= DCACHE_NOKEY_NAME;
        else if (dentry->d_flags & DCACHE_OP_REVALIDATE &&
		 dentry->d_op->d_revalidate == fscrypt_d_revalidate)
		dentry->d_flags &= ~DCACHE_OP_REVALIDATE;
	spin_unlock(&dentry->d_lock);

here + always set ->s_d_op for ext4 and friends (conditional upon
the CONFIG_UNICODE).

No encryption - fine, you get ->is_nokey_name false from the very
beginning, DCACHE_OP_REVALIDATE is cleared and VFS won't ever call
->d_revalidate(); not even the first time.  

Yes, you pay minimal price in dentry_unlink_inode() when we hit
        if (dentry->d_op && dentry->d_op->d_iput)
and bugger off after the second fetch instead of the first one.
I would be quite surprised if it turns out to be measurable,
but if it is, we can always add DCACHE_OP_IPUT to flags.
Similar for ->d_op->d_release (called in the end of
__dentry_kill()).  Again, that only makes sense if we get
a measurable overhead from that.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  parent reply	other threads:[~2023-12-21  7:39 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-15 21:16 [PATCH v2 0/8] Revert setting casefolding dentry operations through s_d_op Gabriel Krisman Bertazi
2023-12-15 21:16 ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-15 21:16 ` [PATCH v2 1/8] dcache: Add helper to disable d_revalidate for a specific dentry Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-15 21:16 ` [PATCH v2 2/8] fscrypt: Drop d_revalidate if key is available Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-19 23:00   ` Eric Biggers
2023-12-19 23:00     ` [f2fs-dev] " Eric Biggers
2023-12-21  7:14   ` Al Viro
2023-12-21  7:14     ` [f2fs-dev] " Al Viro
2023-12-21  7:19     ` Al Viro
2023-12-21  7:19       ` [f2fs-dev] " Al Viro
2023-12-15 21:16 ` [PATCH v2 3/8] libfs: Merge encrypted_ci_dentry_ops and ci_dentry_ops Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-19 22:55   ` Eric Biggers
2023-12-19 22:55     ` [f2fs-dev] " Eric Biggers
2023-12-15 21:16 ` [PATCH v2 4/8] libfs: Expose generic_ci_dentry_ops outside of libfs Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-19 22:56   ` Eric Biggers
2023-12-19 22:56     ` [f2fs-dev] " Eric Biggers
2023-12-15 21:16 ` [PATCH v2 5/8] ext4: Set the case-insensitive dentry operations through ->s_d_op Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-15 21:16 ` [PATCH v2 6/8] f2fs: " Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-15 21:16 ` [PATCH v2 7/8] libfs: Don't support setting casefold operations during lookup Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-15 21:16 ` [PATCH v2 8/8] fscrypt: Move d_revalidate configuration back into fscrypt Gabriel Krisman Bertazi
2023-12-15 21:16   ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-19 23:03   ` Eric Biggers
2023-12-19 23:03     ` [f2fs-dev] " Eric Biggers
2023-12-21  7:39   ` Al Viro [this message]
2023-12-21  7:39     ` Al Viro
2023-12-22  5:58     ` Eric Biggers
2023-12-22  5:58       ` [f2fs-dev] " Eric Biggers
2023-12-19 23:12 ` [PATCH v2 0/8] Revert setting casefolding dentry operations through s_d_op Eric Biggers
2023-12-19 23:12   ` [f2fs-dev] " Eric Biggers
2023-12-23  4:23   ` [PATCH] ovl: Reject mounting case-insensitive filesystems Gabriel Krisman Bertazi
2023-12-23  4:23     ` [f2fs-dev] " Gabriel Krisman Bertazi
2023-12-23  6:20     ` Amir Goldstein
2023-12-23  6:20       ` [f2fs-dev] " Amir Goldstein
2023-12-23  6:22       ` Amir Goldstein
2023-12-23  6:22         ` [f2fs-dev] " Amir Goldstein
2023-12-23 12:46       ` Gabriel Krisman Bertazi
2023-12-23 12:46         ` [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=20231221073940.GC1674809@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=ebiggers@kernel.org \
    --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 \
    /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.