Re: 2.6.22-rc7: known regressions with patches v2

Re: 2.6.22-rc7: known regressions with patches v2

[Christoph Lameter]

On Sat, 7 Jul 2007, Michal Piotrowski wrote:

> > If you're looking for someone to blame, consider the fact that this has
> > gone away now I've switched back to slab. :)
> Yup, I forgot to add Christoph to CC  :)

Hmmmm.. Cannot see the corruption in the dump since it only includes 128 
bytes and it seems to have occurred way into the object. If you want to 
dump 32k to your syslog to see the corruption then look at the 
print_trailer() function and change the parameter of the call to 
print_section

	print_section("Object", p, min(s->objsize, 128));


This is a 32k sized slab and SLAB does not allow debugging on power of two 
slabs > pagesize.... No surprise that SLAB does not complain.

What are these functions "malloc" and "free"? Would be good if those 
would be using kmalloc_track_caller() so that we can figure out who called 
them.

Re: 2.6.22-rc7: known regressions with patches v2

[Linus Torvalds]

On Sat, 7 Jul 2007, Christoph Lameter wrote:
> 
> What are these functions "malloc" and "free"? Would be good if those 
> would be using kmalloc_track_caller() so that we can figure out who called 
> them.

There's not a lot of those around. Looks like it's probably one of

	init/do_mounts_rd.c:static void __init *malloc(size_t size)
	init/initramfs.c:static void __init *malloc(size_t size)

both of which exist just because those things include "lib/inflate.c".

It's probably do_mounts_rd.c, because initramfs.c defines malloc/free 
before the #include, and I would have expected gcc to just inline them in 
that case.

That's probably the right thign to do in do_mounts_rd.c too, rather than 
adding any kmalloc_track_caller() stuff.

		Linus