netdev - Re: [rfc][patch 1/3] slub: fix small HWCACHE

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]

Date:	Wed, 5 Mar 2008 01:28:21 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Christoph Lameter <clameter@....com>, netdev@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	yanmin_zhang@...ux.intel.com, David Miller <davem@...emloft.net>,
	Eric Dumazet <dada1@...mosbay.com>
Subject: Re: [rfc][patch 1/3] slub: fix small HWCACHE_ALIGN alignment

On Mon, Mar 03, 2008 at 11:35:44PM +0200, Pekka Enberg wrote:
> Hi,
> 
> Christoph Lameter wrote:
> >Well the guarantee can only be exploited if you would check the cacheline 
> >sizes and the object size from the code that creates the slab cache. 
> >Basically you would have to guestimate what the slab allocator is doing.
> >
> >So the guarantee is basically meaningless. If the object is larger than a 
> >cacheline then this will never work.
> 
> Yes, I know that. That's why I am asking why this matters. If there's 
> some sort of regression because SLUB does HWCACHE_ALIGN bit differently, 
> we need to fix that.

It started out as a SLUB regression that was exposing poor code in the
percpu allocator due to different SLUB kmalloc alignments. That prompted
some further investigation about the alignment handling in the
allocators and showed up this problem with SLUB's HWCACHE_ALIGN. While
I don't know of a regression caused by it as such, it is totally
unreasonable to just change the semantics of it (seemingly for no good
reason). It is used quite a bit in networking for one, and those guys
count every single cache miss in their fastpaths.


> Not that it necessarily means we have to change 
> HWCACHE_ALIGN but I am assuming Nick has some reason why he wants to 
> introduce the SMP alignment flag.

The SMP flag was just an RFC. I think some people (like Christoph) were
being confused about the HWCACHE_ALIGN flag being for avoiding false
sharing on SMP systems. It would actually be also generally useful to
have the SMP flag (eg. see the sites I added it to in patch #3).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html