linux-kernel - Re: [PATCH] mm, slab: extend kmalloc() alignment for non power-of-two sizes

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: <627741f3-dd28-45b3-ada9-1efeac66351e@suse.cz>
Date: Tue, 2 Jul 2024 23:20:12 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: linux-mm@...ck.org, David Rientjes <rientjes@...gle.com>,
 Christoph Lameter <cl@...ux.com>, Hyeonggon Yoo <42.hyeyoo@...il.com>,
 Kees Cook <keescook@...omium.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Boqun Feng <boqun.feng@...il.com>, rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH] mm, slab: extend kmalloc() alignment for non power-of-two
 sizes

On 7/2/24 11:13 PM, Roman Gushchin wrote:
> On Tue, Jul 02, 2024 at 10:25:44PM +0200, Vlastimil Babka wrote:
>> On 7/2/24 9:30 PM, Roman Gushchin wrote:
>> > On Tue, Jul 02, 2024 at 05:58:01PM +0200, Vlastimil Babka wrote:
>> > Hello Vlastimil,
>> > 
>> > the idea and the implementation makes total sense to me.
>> > 
>> > Do you have an estimate for the memory overhead it will typically introduce?
>> 
>> There's no new overhead for the non-debug case as the layout already
>> naturally has the same alignment as is now guaranteed. Debug has its own
>> overhead so it's enabled only when needed, and this will not add much more.
> 
> Got it, but can you, please, add this note with some explanation why it's true
> to the commit message? Because it's not obvious and the commit message makes

It's there but later:

1) doesn't change the current slab layout (and thus does not increase
   internal fragmentation) when slab debugging is not active

> almost the opposite impression:
>     Slab allocators have been guaranteeing natural alignment for
>     power-of-two sizes <...>, while any other sizes are
>     aligned only to ARCH_KMALLOC_MINALIGN bytes.
> 
> Should it be "guaranteed to be aligned" vs are actually aligned?

Yes that's the case. Will update.

>> 
>> > I don't think it will be too large though and actually can be compensated
>> > by potential performance gains due to a better memory alignment. What do you
>> > think?
>> 
>> Yeah but again, the difference would be only in the debug case and
>> performance gains there are not so interesting :)
> 
> Acked-by: Roman Gushchin <roman.gushchin@...ux.dev>

Thanks!

> Thanks!