Re: [PATCH 1/2] kmemcheck v3

["Vegard Nossum" <vegard.nossum@gmail.com>]

On Feb 7, 2008 11:53 PM, Christoph Lameter <clameter@sgi.com> wrote:
> > Are you sure you are not confusing tracking with tracing? It's only
> > one letter different in spelling, but makes a huge difference in
> > meaning :-)
>
> No I am quite sure what tracking is since the slab allocators have their
> own tracking.
>
> But you may want to explain things better.

Ok, then I think we are still talking about different things :-)

The tracking that kmemcheck does is actually a byte-for-byte tracking
of whether memory has been initialized or not. Think of it as valgrind
for the kernel. We do this by "hiding" pages (marking them non-present
for for MMU) and taking the page faults, which effectively tells us
what memory is being attempted to be read from or written to.

(This generally means that the tracking that kmemcheck does is
page-granular, but we can help this by making entire caches tracked or
non-tracked.)

(This also means that *all* tracked memory allocations require twice
the amount of memory that was requested -- but this is luckily
configurable by disabling kmemcheck entirely :-)).

I chose to implement this in the slab layer because this is probably
where most of the interesting allocations are coming from, and this
gives us a better control over what most users/callers care about,
namely the specific objects.

In a way, kmemcheck is similar to slab poisoning, since that can also
be used to detect the cases where memory is used before it is
initialized. This is a heavier-weight approach, however, and more
precise, as it gives you the exact location of the error.

I hope this clears it up.


Kind regards,
Vegard Nossum