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]

Message-ID: <alpine.DEB.2.00.0907100233560.14601@chino.kir.corp.google.com>
Date:	Fri, 10 Jul 2009 02:41:01 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Nick Piggin <npiggin@...e.de>
cc:	Pekka Enberg <penberg@...helsinki.fi>, Ingo Molnar <mingo@...e.hu>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-kernel@...r.kernel.org, vegard.nossum@...il.com,
	graydon@...hat.com, fche@...hat.com, cl@...ux-foundation.org
Subject: Re: [RFC][PATCH] Check write to slab memory which freed already
 using mudflap

On Fri, 10 Jul 2009, 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.
> 

The design of slqb, to your credit, appears more extendable than slub and 
addressing issues such as the netperf regression (which only manifests 
noticeably on my systems with >= 16 cpus) should be easier since they 
won't be antagonist to the allocator's inherent design.

The reason why I'd like to see slqb merged as a non-default alternative is 
because it exposes the allocator to more benchmarking coverage than would 
be possible in any other environment and attracts much more attention to 
development for those who don't pull Pekka's tree directly.
--
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/