Re: WARNING: kmemcheck: Caught 32-bit read from uninitializedmemory (f6f6e1a4), by kmemleak's scan_block()

[Catalin Marinas]

On Tue, 2009-08-25 at 12:15 +0300, Pekka Enberg wrote:
> On Tue, 2009-08-25 at 10:11 +0100, Catalin Marinas wrote:
> > Yes, that's possible.
> > 
> > Does kmemcheck work on a page-range basis. If an object doesn't cross
> > page boundaries, would it be considered fully initialised after writing
> > a single location?
> > 
> > > I think it would be better to ask kmemcheck on a per-pointer basis
> > > (i.e. for each pointer-sized word in the object), whether it is
> > > initialized or not.
> > 
> > This should work but how expensive is this check?
> 
> Everything in kmemcheck is expensive :-). kmemcheck_shadow_lookup()
> needs to do PTE lookup to find the shadow page where we record object
> states. I'm not sure why that's a problem, though. If you've enabled
> kmemcheck, everything is already dead slow and kmemleak scanning happens
> in background, no? 

It happens in background but the scan_block() function is called, in
most cases, with interrupts disabled and a spinlock held (to avoid the
object being freed during scanning). In my kmemleak branch, queued for
the next merging window, there are patches to allow rescheduling during
object scanning (by releasing the lock temporarily), so it shouldn't be
a problem.

-- 
Catalin

--
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/