[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251107142149.989998-1-mjguzik@gmail.com>
Date: Fri, 7 Nov 2025 15:21:46 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: brauner@...nel.org
Cc: viro@...iv.linux.org.uk,
jack@...e.cz,
linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org,
tytso@....edu,
torvalds@...ux-foundation.org,
josef@...icpanda.com,
linux-btrfs@...r.kernel.org,
Mateusz Guzik <mjguzik@...il.com>
Subject: [PATCH v3 0/3] cheaper MAY_EXEC handling for path lookup
Commit message in patch 1 says it all.
In short, MAY_WRITE checks are elided.
This obsoletes the idea of pre-computing if perm checks are necessary as
that turned out to be too hairy. The new code has 2 more branches per
path component compared to that idea, but the perf difference for
typical paths (< 6 components) was basically within noise. To be
revisited if someone(tm) removes other slowdowns.
Instead of the pre-computing thing I added IOP_FASTPERM_MAY_EXEC so that
filesystems like btrfs can still avoid the hard work.
v3:
- drop the pre-computation idea and inline the perm check
- add IOP_FASTPERM_MAY_EXEC for filesystems with ->permission hooks so
that they can also take advantage of it
Mateusz Guzik (3):
fs: speed up path lookup with cheaper handling of MAY_EXEC
btrfs: utilize IOP_FASTPERM_MAY_EXEC
fs: retire now stale MAY_WRITE predicts in inode_permission()
fs/btrfs/inode.c | 12 +++++++++++-
fs/namei.c | 47 ++++++++++++++++++++++++++++++++++++++++++----
include/linux/fs.h | 13 +++++++------
3 files changed, 61 insertions(+), 11 deletions(-)
--
2.48.1
Powered by blists - more mailing lists