On Thu, Apr 17, 2025 at 12:16 AM Mateusz Guzik <mjguzik@xxxxxxxxx> wrote: > > since path looku is being looked at, two extra nits from me: > > 1. some trivial jump avoidance in inode_permission() > > 2. but more importantly avoiding a memory access which is most likely a > cache miss when descending into devcgroup_inode_permission() > > the file seems to have no maintainer fwiw > > anyhow I'm confident the way forward is to add IOP_FAST_MAY_EXEC (or > similar) to elide inode_permission() in the common case to begin with. > There are quite a few branches which straight up don't need execute. .. the bit would be set if everyone has the x perm on the inode, there are no acls and the thing is a directory The perm to check being MAY_EXEC elides the MAY_WRITE check in sb_permission(). The bit only showing up on directories means this is not a device, eliding devcgroup_inode_permission() The bit being set means there is no need to separately check for the mode and acls. I have hooks in the same spot as security_* callbacks for setattr and setacl + a CONFIG_DEBUG_VFS-guarded runtime check that the bit is only set if there are indeed no acls and the mode grants x for everyone. It also handles races against setattr/getacl. I just need to clean this up + do more testing. > On top of that btrfs has a permission hook only to check for MAY_WRITE, > which in case of path lookup is not set. With the above flag the call > will be avoided. > > Mateusz Guzik (2): > fs: touch up predicts in inode_permission() > device_cgroup: avoid access to ->i_rdev in the common case in > devcgroup_inode_permission() > > fs/namei.c | 10 +++++----- > include/linux/device_cgroup.h | 7 ++++--- > 2 files changed, 9 insertions(+), 8 deletions(-) > > -- > 2.48.1 > -- Mateusz Guzik <mjguzik gmail.com>
