linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gabriel Krisman Bertazi <krisman@suse.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: viro@zeniv.linux.org.uk,  jaegeuk@kernel.org,  tytso@mit.edu,
	linux-ext4@vger.kernel.org,
	 linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org,  amir73il@gmail.com
Subject: Re: [PATCH v3 04/10] fscrypt: Drop d_revalidate once the key is added
Date: Thu, 25 Jan 2024 17:20:56 -0300	[thread overview]
Message-ID: <875xzhxizb.fsf@mailhost.krisman.be> (raw)
In-Reply-To: <20240125031251.GC52073@sol.localdomain> (Eric Biggers's message of "Wed, 24 Jan 2024 19:12:51 -0800")

Eric Biggers <ebiggers@kernel.org> writes:

> On Fri, Jan 19, 2024 at 03:47:36PM -0300, Gabriel Krisman Bertazi wrote:
>> /*
>>  * When d_splice_alias() moves a directory's no-key alias to its plaintext alias
>>  * as a result of the encryption key being added, DCACHE_NOKEY_NAME must be
>>  * cleared.  Note that we don't have to support arbitrary moves of this flag
>>  * because fscrypt doesn't allow no-key names to be the source or target of a
>>  * rename().
>>  */
>>  static inline void fscrypt_handle_d_move(struct dentry *dentry)
>>  {
>>  	dentry->d_flags &= ~DCACHE_NOKEY_NAME;
>> +
>> +	/*
>> +	 * Save the d_revalidate call cost during VFS operations.  We
>> +	 * can do it because, when the key is available, the dentry
>> +	 * can't go stale and the key won't go away without eviction.
>> +	 */
>> +	if (dentry->d_op && dentry->d_op->d_revalidate == fscrypt_d_revalidate)
>> +		dentry->d_flags &= ~DCACHE_OP_REVALIDATE;
>>  }
>
> Is there any way to optimize this further for the case where fscrypt is not
> being used?  This is called unconditionally from d_move().  I've generally been
> trying to avoid things like this where the fscrypt support slows things down for
> everyone even when they're not using the feature.

The problem would be figuring out whether the filesystem has fscrypt
enabled.  I think we can rely on sb->s_cop always being set:

if (sb->s_cop)
   fscrypt_handle_d_move(dentry);

What do you think?

-- 
Gabriel Krisman Bertazi

  reply	other threads:[~2024-01-25 20:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 18:47 [PATCH v3 00/10] Set casefold/fscrypt dentry operations through sb->s_d_op Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 01/10] ovl: Reject mounting case-insensitive filesystems Gabriel Krisman Bertazi
2024-01-25  2:51   ` Eric Biggers
2024-01-25 16:55     ` Gabriel Krisman Bertazi
2024-01-27  7:08       ` Eric Biggers
2024-01-19 18:47 ` [PATCH v3 02/10] fscrypt: Share code between functions that prepare lookup Gabriel Krisman Bertazi
2024-01-25  3:05   ` Eric Biggers
2024-01-25 20:18     ` Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 03/10] fscrypt: Drop d_revalidate for valid dentries during lookup Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 04/10] fscrypt: Drop d_revalidate once the key is added Gabriel Krisman Bertazi
2024-01-25  3:12   ` Eric Biggers
2024-01-25 20:20     ` Gabriel Krisman Bertazi [this message]
2024-01-27  7:17       ` Eric Biggers
2024-01-29 19:34         ` Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 05/10] libfs: Merge encrypted_ci_dentry_ops and ci_dentry_ops Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 06/10] libfs: Add helper to choose dentry operations at mount Gabriel Krisman Bertazi
2024-01-25  3:13   ` Eric Biggers
2024-01-19 18:47 ` [PATCH v3 07/10] ext4: Configure dentry operations at dentry-creation time Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 08/10] f2fs: " Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 09/10] ubifs: " Gabriel Krisman Bertazi
2024-01-19 18:47 ` [PATCH v3 10/10] libfs: Drop generic_set_encrypted_ci_d_ops Gabriel Krisman Bertazi
  -- strict thread matches above, loose matches on Subject: below --
2024-01-11 22:58 [PATCH v3 00/10] Set casefold/fscrypt dentry operations through sb->s_d_op Gabriel Krisman Bertazi
2024-01-11 22:58 ` [PATCH v3 04/10] fscrypt: Drop d_revalidate once the key is added Gabriel Krisman Bertazi
2024-01-18  8:23   ` kernel test robot
2024-01-18 18:58     ` 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=875xzhxizb.fsf@mailhost.krisman.be \
    --to=krisman@suse.de \
    --cc=amir73il@gmail.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).