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: <1247217263.771.8.camel@penberg-laptop>
Date:	Fri, 10 Jul 2009 12:14:23 +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,
	graydon@...hat.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:03 +0200, Nick Piggin wrote:
> > And whether SQLB will replace SLUB remains to be seen.
> > We're still fixing minor issues here and there in SLUB so I have no
> > reason to expect SLQB stabilization to happen overnight which means
> > we're going to have SLUB in the tree for a while anyway.
> 
> I think it's pretty good now. It was the right thing not to merge
> it in this window (seeing as I'd forgotten to make it the default
> in -next). And that flushed out a bug or two. The core logic I
> think is pretty solid now though.

The long-standing PowerPC issue is still open, isnt't it? But anyway, my
main point is that we've already seen from the SLAB to SLUB transition
that while most of the bugs are fixed early on, there's a "fat tail" of
problems ranging from performance regressions to slab corruption which
take a long time to be discovered and fixed up.

And I'm not trying to spread FUD on SLQB here, I'm simply stating the
facts from the previous "slab rewrite" and I have no reason to expect
this one to go any smoother. OTOH, SLQB has already had exposure in
linux-next which hopefully makes merging to mainline less painful
because 95% of the problems are ironed out. But I don't think there's
much we can do about the remaining 5% that only trigger on weird
architectures, workloads, or hardware configurations.

But I think we've been in agreement on this with Nick in the past. So I
guess my rant is directed towards Ingo who seems to be bit too eager to
merge SLQB and rm mm/sl{a,u}b.c :-).

			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/