On Thu, Apr 17, 2025 at 12:16:24AM +0200, Mateusz Guzik 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() Serge did maintain this for a while. But honestly it is an absolute legacy eyesore from the cgroup v1 days. Somehow it was decided that device permission management is a good fit for cgroups. Idk, I have ranted about this in other places at length. No use warming that back up. They later decided to reimplement device access management as a dedicated bpf program type. That imho is another bad design decision. What should've happend is that device access management should've just been implemented through the bpf-LSM infrastructure. That way all this stuff would've gone through security_inode_permission() instead of us having to have two separate calls in inode_permission(). I would love to kill this call. And cgroup v1 is deprecated and systemd has dropped any support for it last year as well. > > 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. Yes. > 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 >
