Re: [RFC][PATCH] Check write to slab memory which freed alreadyusing mudflap

[Ingo Molnar]

* Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:

> Hi Janboe,
> 
> On Thu, Jul 9, 2009 at 7:13 PM, Janboe Ye<yuan-bo.ye@xxxxxxxxxxxx> wrote:
> > slab debug detects the corruption when it allocates and frees the slab. But if someone write to slab memory when it already freed, slab debug could only report its last free point when slab allocates the same block.
> >
> > This information is not enough for debugging when system has complex memory usage. gcc mudflap could insert some check point when a memory is writing and it is helpful to check if the address is writing freed.
> >
> > Because most codes of kernel are drivers, it is most possible that drivers have such problem. So I use mudflap to compile all drivers.
> >
> > kmemcheck is also helpful to check same issue, and it triggers trap every reading and writing, and it need to analysis the instruct which trigger the trap to get the memory address.
> > This heavy depends on the cpu capability. arm has no single-step like x86, so kmemcheck is too heavy to run on real arm system. mudflap way is lighter than kmemcheck for this purpose.
> >
> > As stack allocation is useless for checking slab, kernel mudflap does not implement alloc which is required by gcc mudflap when codes use variable array. So variable array, such as array[i] which i could not determined by compiler, is not supported.
> >
> > Thanks a lot for comments!
> 
> Yeah, something like this makes sense. Some comments below.
> 
> >  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? :-/

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