Messages in this thread | | | Date | Fri, 24 May 2013 20:21:08 -0700 | Subject | Re: Stupid VFS name lookup interface.. | From | Linus Torvalds <> |
| |
On Tue, May 21, 2013 at 3:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Untested patch attached. It compiles cleanly, looks sane, and most of > it is just making the function prototypes look much nicer. I think it > works.
Ok, here's another patch in the "let's make the VFS go faster series". This one, sadly, is not a cleanup.
The concept is simple: right now the inode->i_security pointer chasing kills us on inode security checking with selinux. So let's move two of the fields from the selinux security fields directly into the inode. So instead of doing "inode->i_security->{sid,sclass}", we can just do "inode->{i_sid,i_sclass}" directly.
It's a very mechanical transform, so it should all be good, but the reason I don't much like it is that I think other security models might want to do something like this too, and right now it's selinux-specific. I could imagine making it just an anonymous union of size 64 bits or something, and just making one of the union entries be an (anonymous) struct with those two fields. So it's not conceptually selinux-specific, but right now it's pretty much a selinux hack.
But it's a selinux-specific hack that really does matter. The inode_has_perm() and selinux_inode_permission() functions show up pretty high on kernel profiles that do a lot of filename lookup, and it's pretty much all just that i_security pointer chasing and extra cache miss.
With this, inode->i_security is not very hot any more, and we could move the i_security pointer elsewhere in the inode.
Comments? I don't think this is *pretty* (and I do want to repeat that it's not even tested yet), but I think it's worth it. We've been very good at avoiding extra pointer dereferences in the path lookup, this is one of the few remaining ones.
Linus [unhandled content-type:application/octet-stream] | |