diff options
| author | Mateusz Guzik <mjguzik@gmail.com> | 2025-11-07 15:21:47 +0100 |
|---|---|---|
| committer | Christian Brauner <brauner@kernel.org> | 2025-11-12 12:19:08 +0100 |
| commit | e631df89cd5d638a9d7c152dd9b0a92643efab3e (patch) | |
| tree | 9b5bf1843e53125fd9cde0e4f33a0f9e46991228 /fs/btrfs/inode.c | |
| parent | 854e8df2ce6b02c8be40d6f26bd8aa700b375bb2 (diff) | |
fs: speed up path lookup with cheaper handling of MAY_EXEC
The generic inode_permission() routine does work which is known to be of
no significance for lookup. There are checks for MAY_WRITE, while the
requested permission is MAY_EXEC. Additionally devcgroup_inode_permission()
is called to check for devices, but it is an invariant the inode is a
directory.
Absent a ->permission func, execution lands in generic_permission()
which checks upfront if the requested permission is granted for
everyone.
We can elide the branches which are guaranteed to be false and cut
straight to the check if everyone happens to be allowed MAY_EXEC on the
inode (which holds true most of the time).
Moreover, filesystems which provide their own ->permission routine can
take advantage of the optimization by setting the IOP_FASTPERM_MAY_EXEC
flag on their inodes, which they can legitimately do if their MAY_EXEC
handling matches generic_permission().
As a simple benchmark, as part of compilation gcc issues access(2) on
numerous long paths, for example /usr/lib/gcc/x86_64-linux-gnu/12/crtendS.o
Issuing access(2) on it in a loop on ext4 on Sapphire Rapids (ops/s):
before: 3797556
after: 3987789 (+5%)
Note: this depends on the not-yet-landed ext4 patch to mark inodes with
cache_no_acl()
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://patch.msgid.link/20251107142149.989998-2-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'fs/btrfs/inode.c')
0 files changed, 0 insertions, 0 deletions