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: <ZoRtXgf7g5TU6HSz@google.com>
Date: Tue, 2 Jul 2024 21:13:02 +0000
From: Roman Gushchin <roman.gushchin@...ux.dev>
To: Vlastimil Babka <vbabka@...e.cz>
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 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
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?

> 
> > 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!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ