Messages in this thread Patch in this message | | | Date | Wed, 02 Mar 2005 20:46:23 +0100 | From | Manfred Spraul <> | Subject | Re: Tracing memory leaks (slabs) in 2.6.9+ kernels? |
| |
Andrew Morton wrote:
>OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote: > > >>Andrew Morton <akpm@osdl.org> writes: >> >> > + slab_bufctl(slabp)[objnr] = (unsigned long)caller; >> >> Umm... this patch looks strange.. >> >> slab_bufctl() returns "kmem_bufctl_t *", but kmem_bufctl_t is >> "unsigned short". >> >> > >Good point. This seems to work. > > > Two updates are needed for the leak detection in recent kernels: - set kmem_bufctl_t back to unsigned long - relax the check in check_slabuse, something like the attached patch.
Note that the patch is not tested.
-- Manfred --- 2.6/mm/slab.c 2005-03-02 20:44:47.738737171 +0100 +++ build-2.6/mm/slab.c 2005-03-02 20:44:15.290618759 +0100 @@ -2645,18 +2642,10 @@ red1 = *dbg_redzone1(cachep, objp); red2 = *dbg_redzone2(cachep, objp); - /* simplest case: marked as inactive */ - if (red1 == RED_INACTIVE && red2 == RED_INACTIVE) - continue; - - /* tricky case: if the bufctl value is BUFCTL_ALLOC, then - * the object is either allocated or somewhere in a cpu - * cache. The cpu caches are lockless and there might be - * a concurrent alloc/free call, thus we must accept random - * combinations of RED_ACTIVE and _INACTIVE + /* leak detection stores the caller address in the bufctl, + * thus random combinations of active and inactive are ok */ - if (slab_bufctl(slabp)[i] == BUFCTL_ALLOC && - (red1 == RED_INACTIVE || red1 == RED_ACTIVE) && + if ((red1 == RED_INACTIVE || red1 == RED_ACTIVE) && (red2 == RED_INACTIVE || red2 == RED_ACTIVE)) continue; | |