Re: [PATCH 0/2] two nits for path lookup

[Mateusz Guzik]

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>