All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 12/15] kmemleak: Enable the building of the memory leak detector
Date: Fri, 12 Dec 2008 17:27:06 +0000	[thread overview]
Message-ID: <1229102826.15045.75.camel@pc1117.cambridge.arm.com> (raw)
In-Reply-To: <1228936817.9737.102.camel@nimitz>

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?

Thanks.

-- 
Catalin


  reply	other threads:[~2008-12-12 17:27 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-10 18:26 [PATCH 00/15] Kernel memory leak detector Catalin Marinas
2008-12-10 18:26 ` [PATCH 01/15] kmemleak: Add the base support Catalin Marinas
2008-12-11 22:01   ` Pekka Enberg
2008-12-12 11:36     ` Catalin Marinas
2008-12-12 13:14       ` Pekka Enberg
2008-12-16 19:36   ` Paul E. McKenney
2008-12-17  9:44     ` Catalin Marinas
2008-12-17 17:15       ` Paul E. McKenney
2008-12-10 18:27 ` [PATCH 02/15] kmemleak: Add documentation on the memory leak detector Catalin Marinas
2008-12-10 18:27 ` [PATCH 03/15] kmemleak: Add the slab memory allocation/freeing hooks Catalin Marinas
2008-12-10 18:32   ` Dave Hansen
2008-12-10 18:53   ` Dave Hansen
2008-12-11 21:22   ` Pekka Enberg
2008-12-12 14:27     ` Catalin Marinas
2008-12-18 10:46       ` Pekka Enberg
2008-12-18 16:38         ` Catalin Marinas
2008-12-18 16:49           ` Christoph Lameter
2008-12-18 17:02             ` Catalin Marinas
2008-12-18 19:35               ` Christoph Lameter
2008-12-18 20:06                 ` Pekka Enberg
2008-12-18 21:41                   ` Christoph Lameter
2008-12-19 10:44                     ` Catalin Marinas
2008-12-10 18:27 ` [PATCH 04/15] kmemleak: Add the slob " Catalin Marinas
2008-12-10 18:36   ` Matt Mackall
2008-12-11  9:47     ` Catalin Marinas
2008-12-11 21:37   ` Pekka Enberg
2008-12-10 18:27 ` [PATCH 05/15] kmemleak: Add the slub " Catalin Marinas
2008-12-11 21:30   ` Pekka Enberg
2008-12-12 13:45     ` Catalin Marinas
2008-12-18 10:51       ` Pekka Enberg
2008-12-18 15:28         ` Catalin Marinas
2008-12-18 16:05           ` Pekka Enberg
2008-12-10 18:27 ` [PATCH 06/15] kmemleak: Add the vmalloc " Catalin Marinas
2008-12-10 18:27 ` [PATCH 07/15] kmemleak: Add memleak_alloc callback from alloc_large_system_hash Catalin Marinas
2008-12-10 19:04   ` Dave Hansen
2008-12-11  9:50     ` Catalin Marinas
2008-12-11 10:08       ` Catalin Marinas
2008-12-11 17:30       ` Dave Hansen
2008-12-11 17:38         ` Catalin Marinas
2008-12-11 17:45           ` Dave Hansen
2008-12-11 19:47             ` Pekka Enberg
2008-12-12 17:04               ` Catalin Marinas
2008-12-12 17:17                 ` Dave Hansen
2008-12-12 17:43                   ` Catalin Marinas
2008-12-10 18:27 ` [PATCH 08/15] kmemleak: Add modules support Catalin Marinas
2008-12-10 18:27 ` [PATCH 09/15] x86: Provide _sdata in the vmlinux_*.lds.S files Catalin Marinas
2008-12-10 18:27 ` [PATCH 10/15] arm: Provide _sdata and __bss_stop in the vmlinux.lds.S file Catalin Marinas
2008-12-10 18:27 ` [PATCH 11/15] kmemleak: Remove some of the kmemleak false positives Catalin Marinas
2008-12-10 18:28 ` [PATCH 12/15] kmemleak: Enable the building of the memory leak detector Catalin Marinas
2008-12-10 19:20   ` Dave Hansen
2008-12-12 17:27     ` Catalin Marinas [this message]
2008-12-12 18:02       ` Dave Hansen
2008-12-10 18:28 ` [PATCH 13/15] kmemleak: Keep the __init functions after initialization Catalin Marinas
2008-12-10 18:44   ` Sam Ravnborg
2008-12-17 13:09     ` Catalin Marinas
2008-12-10 18:28 ` [PATCH 14/15] kmemleak: Simple testing module for kmemleak Catalin Marinas
2008-12-10 18:28 ` [PATCH 15/15] kmemleak: Add the corresponding MAINTAINERS entry Catalin Marinas
2008-12-11  9:44 ` [PATCH 00/15] Kernel memory leak detector Catalin Marinas
  -- strict thread matches above, loose matches on Subject: below --
2008-11-29 10:43 Catalin Marinas
2008-11-29 10:44 ` [PATCH 12/15] kmemleak: Enable the building of the " Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1229102826.15045.75.camel@pc1117.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.