linux-kernel - Re: [RFC PATCH] mm/slab: Avoid build bug for calls to kmalloc with a large constant

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9675f4f0-6290-43aa-bf17-6b9c2b461485@suse.cz>
Date: Tue, 26 Nov 2024 13:36:30 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Ryan Roberts <ryan.roberts@....com>,
 Dave Kleikamp <dave.kleikamp@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [RFC PATCH] mm/slab: Avoid build bug for calls to kmalloc with a
 large constant

On 11/26/24 13:18, Ryan Roberts wrote:
> On 14/11/2024 10:09, Vlastimil Babka wrote:
>> On 11/1/24 21:16, Dave Kleikamp wrote:
>>> When boot-time page size is enabled, the test against KMALLOC_MAX_CACHE_SIZE
>>> is no longer optimized out with a constant size, so a build bug may
>>> occur on a path that won't be reached.
>> 
>> That's rather unfortunate, the __builtin_constant_p(size) part of
>> kmalloc_noprof() really expects things to resolve at compile time and it
>> would be better to keep it that way.
>> 
>> I think it would be better if we based KMALLOC_MAX_CACHE_SIZE itself on
>> PAGE_SHIFT_MAX and kept it constant, instead of introducing
>> KMALLOC_SHIFT_HIGH_MAX only for some sanity checks.
>> 
>> So if the kernel was built to support 4k to 64k, but booted as 4k, it would
>> still create and use kmalloc caches up to 128k. SLUB should handle that fine
>> (if not, please report it :)
> 
> So when PAGE_SIZE_MAX=64K and PAGE_SIZE=4K, kmalloc will support up to 128K
> whereas before it only supported up to 8K. I was trying to avoid that since I
> assumed that would be costly in terms of extra memory allocated for those higher
> order buckets that will never be used. But I have no idea how SLUB works in
> practice. Perhaps memory for the cache is only lazily allocated so we won't see
> an issue in practice?

Yes the e.g. 128k slabs themselves will be lazily allocated. There will be
some overhead with the management structures (struct kmem_cache etc) but
much smaller.
To be completely honest, some extra overhead might come to be when the slabs
are allocated ans later the user frees those allocations. kmalloc_large()
wwould return them immediately, while a regular kmem_cache will keep one or
more per cpu for reuse. But if that becomes a visible problem we can tune
those caches to discard slabs more aggressively.

> I'm happy to make this change if you're certain it's the right approach; please
> confirm.

Yes it's much better option than breaking the build-time-constant part of
kmalloc_noprof().

>> 
>> Maybe we could also stop adding + 1 to PAGE_SHIFT_MAX if it's >=64k, so the
>> cache size is max 64k and not 128k but that should be probably evaluated
>> separately from this series.
> 
> I'm inferring from this that perhaps there is a memory cost with having the
> higher orders defined but unused.

Yeah as per above, should not be too large and we could tune it down if
necessary.

> Thanks,
> Ryan
> 
>> 
>> Vlastimil
>> 
>>> Found compiling drivers/net/ethernet/qlogic/qed/qed_sriov.c
>>>
>>> Signed-off-by: Dave Kleikamp <dave.kleikamp@...cle.com>
>>> ---
>>>
>>> Ryan,
>>>
>>> Please consider incorporating this fix or something similar into your
>>> mm patch in the boot-time pages size patches.
>>>
>>>   include/linux/slab.h | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/slab.h b/include/linux/slab.h
>>> index 9848296ca6ba..a4c7507ab8ec 100644
>>> --- a/include/linux/slab.h
>>> +++ b/include/linux/slab.h
>>> @@ -685,7 +685,8 @@ static __always_inline unsigned int __kmalloc_index(size_t size,
>>>   	if (size <= 1024 * 1024) return 20;
>>>   	if (size <=  2 * 1024 * 1024) return 21;
>>>   
>>> -	if (!IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant)
>>> +	if (!IS_ENABLED(CONFIG_ARM64_BOOT_TIME_PAGE_SIZE) &&
>>> +	    !IS_ENABLED(CONFIG_PROFILE_ALL_BRANCHES) && size_is_constant)
>>>   		BUILD_BUG_ON_MSG(1, "unexpected size in kmalloc_index()");
>>>   	else
>>>   		BUG();
>> 
>