[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGudoHFs7-mRfjuMQ8skA23Gg7uxCSGqJgXnyrcKz-ZBv8ALCA@mail.gmail.com>
Date: Thu, 6 Nov 2025 23:45:11 +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
Subject: Re: [PATCH v2 1/4] fs: speed up path lookup with cheaper MAY_EXEC checks
On Thu, Nov 6, 2025 at 7:01 PM Mateusz Guzik <mjguzik@...il.com> wrote:
> diff --git a/fs/posix_acl.c b/fs/posix_acl.c
> index 4050942ab52f..da27dd536058 100644
> --- a/fs/posix_acl.c
> +++ b/fs/posix_acl.c
> @@ -1135,6 +1135,7 @@ int vfs_set_acl(struct mnt_idmap *idmap, struct dentry *dentry,
> error = -EIO;
> if (!error) {
> fsnotify_xattr(dentry);
> + inode_recalc_fast_may_exec(inode);
> security_inode_post_set_acl(dentry, acl_name, kacl);
> }
>
I just some found I missed some spots which need to call
inode_recalc_fast_may_exec().
I plugged them locally, but now I have to chew on whether this is
worth the potential bugs.
Preferably there would be magic catching all changes to i_mode and
acls requiring inode_recalc_fast_may_exec() is called before the inode
gets unlocked.
I'm going to play with implementing inode_permission_may_setattr which
starts with explicitly checking for i_mode being available for
everyone and no acls being present, maybe that's already almost
entirety of the speed up with no woes like the above to worry about.
Powered by blists - more mailing lists