fs: touch up predicts in inode_permission()

The routine only encounters errors when people try to access things they
can't, which is a negligible amount of calls.

The only questionable bit might be the pre-existing predict around
MAY_WRITE. Currently the routine is predominantly used for MAY_EXEC, so
this makes some sense.

I verified this straightens out the asm.

Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/20250416221626.2710239-2-mjguzik@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>

diff --git a/fs/namei.c b/fs/namei.c
index b9cc03faa03350500bdbf1fd39338e9b9cc83699..b051211f064c50bb6ed7b5e85c4f7c56ca1be035 100644 (file)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -571,14 +571,14 @@ int inode_permission(struct mnt_idmap *idmap,
        int retval;
 
        retval = sb_permission(inode->i_sb, inode, mask);
-       if (retval)
+       if (unlikely(retval))
                return retval;
 
        if (unlikely(mask & MAY_WRITE)) {
                /*
                 * Nobody gets write access to an immutable file.
                 */
-               if (IS_IMMUTABLE(inode))
+               if (unlikely(IS_IMMUTABLE(inode)))
                        return -EPERM;
 
                /*
@@ -586,16 +586,16 @@ int inode_permission(struct mnt_idmap *idmap,
                 * written back improperly if their true value is unknown
                 * to the vfs.
                 */
-               if (HAS_UNMAPPED_ID(idmap, inode))
+               if (unlikely(HAS_UNMAPPED_ID(idmap, inode)))
                        return -EACCES;
        }
 
        retval = do_inode_permission(idmap, inode, mask);
-       if (retval)
+       if (unlikely(retval))
                return retval;
 
        retval = devcgroup_inode_permission(inode, mask);
-       if (retval)
+       if (unlikely(retval))
                return retval;
 
        return security_inode_permission(inode, mask);