Re: [RFC][PATCH 10/13] get rid of audit_reusename()
Linus Torvalds <[email protected]>
| Newsgroups | org.kernel.vger.audit,org.kernel.vger.io-uring,org.kernel.vger.linux-fsdevel |
|---|---|
| Message-ID | <CAHk-=wghq+wJrgrDy=-S5TmVNkaJS5RWsQ3kFfCCwv0juoKG4w@mail.gmail.com> |
On Sun, 9 Nov 2025 at 14:44, Linus Torvalds <[email protected]> wrote: > > And again: that patch will slow things down [..] Having done a profile just to see, the regular allocation path (getname_flags -> kmem_cache_alloc_noprof) certainly shows up. But on that test set (kernel build), I never hit the 128-byte limit, and interestingly putname() shows up a tiny bit more than getname_flags(). At least one reason seems to be that the if (refcnt != 1) { thing in putname() is mispredicted, and without the auditing code, the "refcnt == 1" case is obviously the common case. Anyway. Not a great test, and this is all the "good behavior", and all the *real* costs in that particular path are in strncpy_from_user(), kmem_cache_free() and kmem_cache_alloc_noprof(). And yeah, STAC/CLAC is expensive on my old Zen 2 machine, as are the cmpxchg16b in the slab alloc/free paths. And in the end, the actual path walking is more expensive than all of this, as is selinux_inode_permission(). So the actual filename copying isn't *really* all that noticeable - you have to look for it. Linus