Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

[Manfred Spraul <manfred@colorfullife.com>]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

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

[-- Attachment #2: patch-recent-leak --]
[-- Type: text/plain, Size: 973 bytes --]

--- 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;