linux-kernel - Re: [RFC][PATCH] Check write to slab memory which freed already using mudflap

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:	Fri, 10 Jul 2009 12:40:26 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Ingo Molnar <mingo@...e.hu>, Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-kernel@...r.kernel.org, vegard.nossum@...il.com,
	fche@...hat.com, cl@...ux-foundation.org
Subject: Re: [RFC][PATCH] Check write to slab memory which freed already
 using mudflap

Hi Nick,

On Fri, 2009-07-10 at 11:29 +0200, Nick Piggin wrote:
> What I would like to see is we eventualy make the hard decision
> and cull 2 of them. If SLQB is not clearly better (or, if it is
> clearly worse) than the other allocators and it can't be improved,
> then it has failed my goals for it and I would prefer to remove it
> from the tree.

I'm not sure it's such a hard decision. SLAB is on it's way out because
SLUB and SLQB code are much cleaner and the debugging support is better.
As for SLUB vs. SLQB, I'm hoping to trick you, Mel, and others into
doing an "epic slab allocator performance battle" and post the numbers
once we have have everything merged to mainline. My gut feeling is that
SLQB is in the lead because SLUB hasn't addressed the Intel regression.

			Pekka

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/