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

[Catalin Marinas <catalin.marinas@arm.com>]

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