[lkml]   [2008]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 12/15] kmemleak: Enable the building of the memory leak detector
On Wed, 2008-12-10 at 11:20 -0800, Dave Hansen wrote:
> On Wed, 2008-12-10 at 18:28 +0000, Catalin Marinas wrote:
> > +config DEBUG_MEMLEAK
> > + bool "Kernel memory leak detector"
> > + default n
> > + depends on EXPERIMENTAL
> > + select DEBUG_SLAB if SLAB
> > + select SLUB_DEBUG if SLUB
> > + select DEBUG_FS
> > + select STACKTRACE
> > + select FRAME_POINTER
> > + select KALLSYMS
> So, not all architectures have STACKTRACE or FRAME_POINTER. I think a
> few of these should at least be done with depends.

I think it could depend on STACKTRACE_SUPPORT. Alternatively, it could
select STACKTRACE only if it is supported, though for architectures
without it, the kmemleak reports wouldn't be very useful.

Does FRAME_POINTER even matter? I think STACKTRACE should be enough to
get the backtrace. I even have some ARM patches for stack unwinding
where FRAME_POINTER is disabled (and shouldn't be enabled).

> Is this feature accessible if DEBUG_FS=n? It seems to compile OK, but I
> wonder if it is useful.

Well, it is recommended. If you don't have this, you can't trigger a
scan manually by reading the /sys/kernel/debug/memleak file (have to
rely on the automatic thread). In my local tree (not published yet), I
also added support for run-time configuration by writing to this file.
Is there any disadvantage in always selecting DEBUG_FS?



 \ /
  Last update: 2008-12-12 18:29    [W:0.108 / U:2.160 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site