Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible

From: Mateusz Guzik <mjguzik@gmail.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Alexander Potapenko <glider@google.com>,
	Kees Cook <keescook@chromium.org>,
	Eric Biggers <ebiggers@google.com>,
	Christian Brauner <brauner@kernel.org>,
	serge@hallyn.com, paul@paul-moore.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible
Date: Sat, 4 Mar 2023 21:42:21 +0100	[thread overview]
Message-ID: <CAGudoHFf87OmvmS-wm92MyPC-3yyXMUw=-BTzSNmVLXrk55U5A@mail.gmail.com> (raw)
In-Reply-To: <ZAOnsOl+cXk9mTj5@ZenIV>

On 3/4/23, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Mar 03, 2023 at 09:39:11PM +0100, Mateusz Guzik wrote:
>
>> the allocation routine does not have any information about the size
>> available at compilation time, so has to resort to a memset call at
>> runtime. Instead, should this be:
>>
>> f = kmem_cache_alloc(...);
>> memset(f, 0, sizeof(*f));
>>
>> ... the compiler could in principle inititalize stuff as indicated by
>> code and emit zerofill for the rest. Interestingly, last I checked
>> neither clang nor gcc knew how to do it, they instead resort to a full
>> sized memset anyway, which is quite a bummer.
>
> For struct file I wouldn't expect a win from that, TBH.
>

That was mostly for illustrative purposes, but you are right -- turns
out the slab is 256 bytes in size per obj and only a small fraction of
it is inititalized in the allocation routine. Good candidate to always
punt to memset in the allocator as it happens now.

Bummer though, it is also one of the 2 most memset'ed during kernel
build. The other one allocated at the same rate is lsm_file_cache and
that's only 32 bytes in size, so it will get a win.

-- 
Mateusz Guzik <mjguzik gmail.com>