diff options
author | Gabriel Krisman Bertazi <krisman@suse.de> | 2024-02-21 12:14:05 -0500 |
---|---|---|
committer | Gabriel Krisman Bertazi <krisman@suse.de> | 2024-02-27 16:55:34 -0500 |
commit | e86e6638d1171c2201ffff16d2c6a6fd975f8383 (patch) | |
tree | b5cdab6dae43797c6f40bcc7d0a0a77e30d5612e /tools/perf/scripts/python/exported-sql-viewer.py | |
parent | 8b6bb995d3819218498bdbee4465bffff1497a31 (diff) | |
download | linux-e86e6638d1171c2201ffff16d2c6a6fd975f8383.tar.gz linux-e86e6638d1171c2201ffff16d2c6a6fd975f8383.tar.bz2 linux-e86e6638d1171c2201ffff16d2c6a6fd975f8383.zip |
fscrypt: Drop d_revalidate for valid dentries during lookup
Unencrypted and encrypted-dentries where the key is available don't need
to be revalidated by fscrypt, since they don't go stale from under VFS
and the key cannot be removed for the encrypted case without evicting
the dentry. Disable their d_revalidate hook on the first lookup, to
avoid repeated revalidation later. This is done in preparation to always
configuring d_op through sb->s_d_op.
The only part detail is that, since the filesystem might have other
features that require revalidation, we only apply this optimization if
the d_revalidate handler is fscrypt_d_revalidate itself.
Finally, we need to clean the dentry->flags even for unencrypted
dentries, so the ->d_lock might be acquired even for them. In order to
avoid doing it for filesystems that don't care about fscrypt at all, we
peek ->d_flags without the lock at first, and only acquire it if we
actually need to write the flag.
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20240221171412.10710-4-krisman@suse.de
Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
Diffstat (limited to 'tools/perf/scripts/python/exported-sql-viewer.py')
0 files changed, 0 insertions, 0 deletions