Messages in this thread | | | Date | Fri, 8 Feb 2008 00:18:21 +0100 | From | "Vegard Nossum" <> | Subject | Re: [PATCH 1/2] kmemcheck v3 |
| |
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
| |