Messages in this thread | | | Date | Fri, 10 Jul 2009 11:03:51 +0200 | From | Nick Piggin <> | Subject | Re: [RFC][PATCH] Check write to slab memory which freed already using mudflap |
| |
On Fri, Jul 10, 2009 at 11:52:00AM +0300, Pekka Enberg wrote: > Hi Ingo, > > On Fri, 2009-07-10 at 10:47 +0200, Ingo Molnar wrote: > > > > arch/arm/include/asm/elf.h | 1 + > > > > arch/arm/kernel/module.c | 1 + > > > > drivers/Makefile | 4 +- > > > > include/mf-runtime.h | 42 ++++++++++++++ > > > > kernel/Makefile | 2 +- > > > > kernel/mudflap.c | 132 ++++++++++++++++++++++++++++++++++++++++++++ > > > > lib/Kconfig.debug | 7 ++ > > > > mm/slab.c | 53 ++++++++++++++++++ > > > > 8 files changed, 240 insertions(+), 2 deletions(-) > > > > > > SLAB is (slowly) going away so you might want to port this to SLUB > > > as well so we can merge both. > > > > and SLQB which will replace both? :-/ > > Well, I cannot really expect people to port patches to SLQB until it's > in mainline.
I agree...
slab allocator's primary metric is performance, and debugging features can tend to be added very easily after that (because there is a performance hit accepted). So I have not been spending much time on those in SLQB.
If it gets merged and decided to stay based on performance results, then I will do more to port over other debug features.
> 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.
| |