lkml.org 
[lkml]   [2013]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [PATCH] slub: Proper kmemleak tracking if CONFIG_SLUB_DEBUG disabled
On Wed, 2 Oct 2013, Bird, Tim wrote:

> The problem child is actually the unconditional call to kmemleak_alloc()
> in kmalloc_large_node() (in slub.c). The problem comes because that call
> is unconditional on CONFIG_SLUB_DEBUG but the kmemleak
> calls in the hook routines are conditional on CONFIG_SLUB_DEBUG.
> So if you have CONFIG_SLUB_DEBUG=n but CONFIG_DEBUG_KMEMLEAK=y,
> you get the false reports.

Right. You need to put the #ifdef CONFIG_SLUB_DEBUG around the hooks that
need it in the function itself instead of disabling the whole function if
CONFIG_SLUB_DEUBG is not set.

> Now, there are kmemleak calls in kmalloc_large_node() and kfree() that don't
> follow the "hook" pattern. Should these be moved to 'hook' routines, to keep
> all the checks in the hooks?

That would be great.

> Personally, I like the idea of keeping bookeeping/tracing/debug stuff in hook
> routines. I also like de-coupling CONFIG_SLUB_DEBUG and CONFIG_DEBUG_KMEMLEAK,
> but maybe others have a different opinon. Unless someone speaks up, we'll
> move the the currently in-function kmemleak calls into hooks, and all of the
> kmemleak stuff out from under CONFIG_SLUB_DEBUG.
> We'll have to see if the ifdefs get a little messy.

Decouple of you want. CONFIG_SLUB_DEBUG may duplicate what you already do.



\
 
 \ /
  Last update: 2013-10-02 18:21    [W:0.111 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site