Messages in this thread | | | Subject | Re: [PATCH 05/15] kmemleak: Add the slub memory allocation/freeing hooks | From | Catalin Marinas <> | Date | Thu, 18 Dec 2008 15:28:55 +0000 |
| |
Hi Pekka,
On Thu, 2008-12-18 at 12:51 +0200, Pekka Enberg wrote: > On Fri, 2008-12-12 at 13:45 +0000, Catalin Marinas wrote: > > Pekka Enberg wrote: > > > Hmm, I'm not sure I understand why struct kmem_cache_cpu ->freelist is > > > never scanned. > > > > Why would the ->freelist be a problem? I don't fully understand the slub > > allocator. Aren't objects added to the freelist only after they were > > freed? In __slab_alloc there seems to be a line: > > > > c->page->freelist = NULL; > > > > so the freelist won't count as a reference anymore. After freeing an > > object, kmemleak no longer cares about references to it. > > I think we're talking about two different things here. Don't we then > have false negatives because we reach ->freelist of struct > kmem_cache_cpu which contains a pointer to an object that is free'd > (take a look at slab_free() fast-path)?
Just to make sure I understand it correctly, the slab_free() fast path stores the pointer to the freed object into c->freelist. However, this object is no longer tracked by kmemleak because of the kmemleak_free_recursive() call at the beginning of this function (false negatives make sense only for allocated objects).
On the slab_alloc() fast path, the pointer to an allocated object is obtained from the c->freelist pointer but this seems to be overridden by the pointer to the next free object, object[c->offset], which isn't yet tracked by kmemleak. So, during a memory scan, it shouldn't matter that the kmem_cache_cpu structures are called as they don't contain any pointer to an allocated (not free) object.
The new slabs are allocated with alloc_pages() and these are not tracked by kmemleak.
Is my understanding correct? Thanks.
-- Catalin
| |