From 875ccc0ddceead3998d9ffd1e68f1290efa1f9a9 Mon Sep 17 00:00:00 2001 From: Mateusz Guzik Date: Thu, 17 Apr 2025 00:16:25 +0200 Subject: [PATCH 1/2] 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 Link: https://lore.kernel.org/20250416221626.2710239-2-mjguzik@gmail.com Signed-off-by: Christian Brauner --- fs/namei.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index b9cc03faa033..b051211f064c 100644 --- 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); From 4ef4ac360101f8bb11b6486ce60cd60ca015be8c Mon Sep 17 00:00:00 2001 From: Mateusz Guzik Date: Thu, 17 Apr 2025 00:16:26 +0200 Subject: [PATCH 2/2] device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission() The routine gets called for every path component during lookup. ->i_mode is going to be cached on account of permission checks, while ->i_rdev is an area which is most likely cache-cold. gcc 14.2 is kind enough to emit one branch: movzwl (%rbx),%eax mov %eax,%edx and $0xb000,%dx cmp $0x2000,%dx je 11bc This patch is lazy in that I don't know if the ->i_rdev branch makes any sense with the newly added mode check upfront. I am not changing any semantics here though. Signed-off-by: Mateusz Guzik Link: https://lore.kernel.org/20250416221626.2710239-3-mjguzik@gmail.com Signed-off-by: Christian Brauner --- include/linux/device_cgroup.h | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/include/linux/device_cgroup.h b/include/linux/device_cgroup.h index d02f32b7514e..0864773a57e8 100644 --- a/include/linux/device_cgroup.h +++ b/include/linux/device_cgroup.h @@ -18,15 +18,16 @@ static inline int devcgroup_inode_permission(struct inode *inode, int mask) { short type, access = 0; + if (likely(!S_ISBLK(inode->i_mode) && !S_ISCHR(inode->i_mode))) + return 0; + if (likely(!inode->i_rdev)) return 0; if (S_ISBLK(inode->i_mode)) type = DEVCG_DEV_BLOCK; - else if (S_ISCHR(inode->i_mode)) + else /* S_ISCHR by the test above */ type = DEVCG_DEV_CHAR; - else - return 0; if (mask & MAY_WRITE) access |= DEVCG_ACC_WRITE;