diff options
author | Gabriel Krisman Bertazi <krisman@suse.de> | 2024-02-21 12:14:06 -0500 |
---|---|---|
committer | Gabriel Krisman Bertazi <krisman@suse.de> | 2024-02-27 16:55:34 -0500 |
commit | e9b10713e82c98a0a909ac55bd485b7d7ff91b85 (patch) | |
tree | 181c02e72ab29fff0d850965174a06814f8fa750 /fs | |
parent | e86e6638d1171c2201ffff16d2c6a6fd975f8383 (diff) | |
download | lwn-e9b10713e82c98a0a909ac55bd485b7d7ff91b85.tar.gz lwn-e9b10713e82c98a0a909ac55bd485b7d7ff91b85.zip |
fscrypt: Drop d_revalidate once the key is added
When a key is added, existing directory dentries in the
DCACHE_NOKEY_NAME form are moved by the VFS to the plaintext version.
But, since they have the DCACHE_OP_REVALIDATE flag set, revalidation
will be done at each lookup only to return immediately, since plaintext
dentries can't go stale until eviction. This patch optimizes this case,
by dropping the flag once the nokey_name dentry becomes plain-text.
Note that non-directory dentries are not moved this way, so they won't
be affected.
Of course, this can only be done if fscrypt is the only thing requiring
revalidation for a dentry. For this reason, we only disable
d_revalidate if the .d_revalidate hook is fscrypt_d_revalidate itself.
It is safe to do it here because when moving the dentry to the
plain-text version, we are holding the d_lock. We might race with a
concurrent RCU lookup but this is harmless because, at worst, we will
get an extra d_revalidate on the keyed dentry, which will still find the
dentry to be valid.
Finally, now that we do more than just clear the DCACHE_NOKEY_NAME in
fscrypt_handle_d_move, skip it entirely for plaintext dentries, to avoid
extra costs.
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20240221171412.10710-5-krisman@suse.de
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions