The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>
To: "Catalin Marinas" <catalin.marinas@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9
Date: Sun, 13 Aug 2006 13:59:46 +0200	[thread overview]
Message-ID: <6bffcb0e0608130459k1c7e142esbfc2439badf323bd@mail.gmail.com> (raw)
In-Reply-To: <20060812215857.17709.79502.stgit@localhost.localdomain>

Hi Catalin,

On 12/08/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> This is a new version (0.9) of the kernel memory leak detector. See
> the Documentation/kmemleak.txt file for a more detailed
> description. The patches are downloadable from (the whole patch or the
> broken-out series):
>
> http://homepage.ntlworld.com/cmarinas/kmemleak/patch-2.6.18-rc4-kmemleak-0.9.bz2
> http://homepage.ntlworld.com/cmarinas/kmemleak/broken-out/patches-kmemleak-0.9.tar.bz2

Can you look at this?

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
events/0/8 is trying to acquire lock:
 (old_style_spin_init){++..}, at: [<c017674f>] memleak_free+0x95/0x157

but task is already holding lock:
 (&parent->list_lock){++..}, at: [<c0174f29>] drain_array+0x49/0xad

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&parent->list_lock){++..}:
       [<c0140cc7>] check_prevs_add+0x4d/0xaf
       [<c01423c1>] __lock_acquire+0x7b1/0x814
       [<c01429bc>] lock_acquire+0x5e/0x7e
       [<c02f9f7a>] _spin_lock+0x23/0x2f
       [<c0174058>] cache_alloc_refill+0x76/0x1d2
       [<c0174559>] kmem_cache_alloc+0x73/0xce
       [<c01f0c8a>] radix_tree_node_alloc+0x1a/0x51
       [<c01f0e3f>] radix_tree_insert+0x51/0xfb
       [<c01761f6>] insert_alias+0x85/0xe8
       [<c01762a4>] memleak_insert_aliases+0x4b/0xa6
       [<c01773f7>] memleak_init+0x44/0xf5
       [<c0100ab0>] start_kernel+0x17e/0x1f9
       [<c0100210>] 0xc0100210
-> #0 (old_style_spin_init){++..}:
       [<c0140cc7>] check_prevs_add+0x4d/0xaf
       [<c01423c1>] __lock_acquire+0x7b1/0x814
       [<c01429bc>] lock_acquire+0x5e/0x7e
       [<c02f9f7a>] _spin_lock+0x23/0x2f
       [<c017674f>] memleak_free+0x95/0x157
       [<c0174a74>] kmem_cache_free+0x62/0xbc
       [<c0172fc8>] slab_destroy+0x48/0x4d
       [<c01743b8>] free_block+0xc9/0x101
       [<c0174f65>] drain_array+0x85/0xad
       [<c017500d>] cache_reap+0x80/0xfe
       [<c01394dd>] run_workqueue+0x88/0xc4
       [<c0139617>] worker_thread+0xfe/0x131
       [<c013c6e1>] kthread+0x82/0xaa
       [<c01044c9>] kernel_thread_helper+0x5/0xb

other info that might help us debug this:

2 locks held by events/0/8:
 #0:  (cache_chain_mutex){--..}, at: [<c0174f9d>] cache_reap+0x10/0xfe
 #1:  (&parent->list_lock){++..}, at: [<c0174f29>] drain_array+0x49/0xad
stack backtrace:
 [<c0106e59>] show_trace_log_lvl+0x58/0x14c
 [<c0106f5a>] show_trace+0xd/0xf
 [<c010702c>] dump_stack+0x17/0x19
 [<c01405c0>] print_circular_bug_tail+0x59/0x62
 [<c0140af1>] check_prev_add+0x2b/0x1b4
 [<c0140cc7>] check_prevs_add+0x4d/0xaf
 [<c01423c1>] __lock_acquire+0x7b1/0x814
 [<c01429bc>] lock_acquire+0x5e/0x7e
 [<c02f9f7a>] _spin_lock+0x23/0x2f
 [<c017674f>] memleak_free+0x95/0x157
 [<c0174a74>] kmem_cache_free+0x62/0xbc
 [<c0172fc8>] slab_destroy+0x48/0x4d
 [<c01743b8>] free_block+0xc9/0x101
 [<c0174f65>] drain_array+0x85/0xad
 [<c017500d>] cache_reap+0x80/0xfe
 [<c01394dd>] run_workqueue+0x88/0xc4
 [<c0139617>] worker_thread+0xfe/0x131
  [<c013c6e1>] kthread+0x82/0xaa
 [<c01044c9>] kernel_thread_helper+0x5/0xb
DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb
Leftover inexact backtrace:
 [<c0106f5a>] show_trace+0xd/0xf
 [<c010702c>] dump_stack+0x17/0x19
 [<c01405c0>] print_circular_bug_tail+0x59/0x62
 [<c0140af1>] check_prev_add+0x2b/0x1b4
 [<c0140cc7>] check_prevs_add+0x4d/0xaf
 [<c01423c1>] __lock_acquire+0x7b1/0x814
 [<c01429bc>] lock_acquire+0x5e/0x7e
 [<c02f9f7a>] _spin_lock+0x23/0x2f
 [<c017674f>] memleak_free+0x95/0x157
 [<c0174a74>] kmem_cache_free+0x62/0xbc
 [<c0172fc8>] slab_destroy+0x48/0x4d
 [<c01743b8>] free_block+0xc9/0x101
 [<c0174f65>] drain_array+0x85/0xad
 [<c017500d>] cache_reap+0x80/0xfe
 [<c01394dd>] run_workqueue+0x88/0xc4
 [<c0139617>] worker_thread+0xfe/0x131
  [<c013c6e1>] kthread+0x82/0xaa
 [<c01044c9>] kernel_thread_helper+0x5/0xb

0xc017674f is in memleak_free (/usr/src/linux-work3/mm/memleak.c:479).
474     /* Remove a pointer and its aliases from the pointer radix tree */
475     static inline void delete_pointer(unsigned long ptr)
476     {
477             struct memleak_pointer *pointer;
478
479             pointer = radix_tree_delete(&pointer_tree, ptr);
480             if (!pointer) {
481                     dump_stack();
482                     printk(KERN_WARNING "kmemleak: freeing unknown
pointer value 0x%08lx\n", ptr);
483                     return;

0xc0174f29 is in drain_array (/usr/src/linux-work3/mm/slab.c:3739).
3734                    return;
3735            if (ac->touched && !force) {
3736                    ac->touched = 0;
3737            } else {
3738                    spin_lock_irq(&l3->list_lock);
3739                    if (ac->avail) {
3740                            tofree = force ? ac->avail :
(ac->limit + 4) / 5;
3741                            if (tofree > ac->avail)
3742                                    tofree = (ac->avail + 1) / 2;
3743                            free_block(cachep, ac->entry, tofree, node);

0xc0174f9d is in cache_reap (/usr/src/linux-work3/mm/slab.c:3770).
3765    {
3766            struct kmem_cache *searchp;
3767            struct kmem_list3 *l3;
3768            int node = numa_node_id();
3769
3770            if (!mutex_trylock(&cache_chain_mutex)) {
3771                    /* Give up. Setup the next iteration. */
3772                    schedule_delayed_work(&__get_cpu_var(reap_work),
3773                                          REAPTIMEOUT_CPUC);
3774                    return;

config file and dmesg http://www.stardust.webpages.pl/files/o_bugs/kmemleak-0.9/

> --
> Catalin

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

  parent reply	other threads:[~2006-08-13 11:59 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-12 21:58 [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9 Catalin Marinas
2006-08-12 21:59 ` [PATCH 2.6.18-rc4 01/10] Base support for kmemleak Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 02/10] Some documentation " Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 03/10] Add the memory allocation/freeing hooks " Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 04/10] Modules support " Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 05/10] Add kmemleak support for i386 Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 06/10] Add kmemleak support for ARM Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 07/10] Remove some of the kmemleak false positives Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 08/10] Keep the __init functions after initialization Catalin Marinas
2006-08-12 22:00 ` [PATCH 2.6.18-rc4 09/10] Simple testing for kmemleak Catalin Marinas
2006-08-12 22:01 ` [PATCH 2.6.18-rc4 10/10] Update the MAINTAINERS file " Catalin Marinas
2006-08-13 11:59 ` Michal Piotrowski [this message]
2006-08-13 14:13   ` [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9 Catalin Marinas
2006-08-13 14:26     ` Michal Piotrowski
2006-08-17 13:02       ` Catalin Marinas
2006-08-17 14:45         ` Michal Piotrowski
2006-08-17 14:48           ` Michal Piotrowski
2006-08-17 15:04             ` Catalin Marinas
2006-08-17 15:01           ` Catalin Marinas
2006-08-17 21:58             ` Catalin Marinas
2006-08-18 12:28               ` Michal Piotrowski
2006-08-18 13:27                 ` Catalin Marinas
2006-08-18 13:55                   ` Michal Piotrowski
2006-08-18 14:15                     ` Michal Piotrowski
2006-08-18 15:46                       ` Catalin Marinas
2006-08-18 16:42                         ` Michal Piotrowski
2006-08-18 16:57                           ` Catalin Marinas
2006-08-18 21:38                             ` Michal Piotrowski
2006-08-18 21:47                               ` Catalin Marinas
2006-08-18 22:49                                 ` Michal Piotrowski
2006-08-19 10:07                                   ` Catalin Marinas
2006-08-19 11:20                                     ` Antonino A. Daplas
2006-08-19 13:25                                       ` Catalin Marinas
2006-08-19 10:27                                   ` Catalin Marinas
2006-08-19 10:32                                     ` Michal Piotrowski
2006-08-29 21:06         ` Catalin Marinas
2006-08-14 15:34   ` Catalin Marinas
2006-08-15 15:25     ` Catalin Marinas
2006-08-15 15:26       ` 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=6bffcb0e0608130459k1c7e142esbfc2439badf323bd@mail.gmail.com \
    --to=michal.k.k.piotrowski@gmail.com \
    --cc=catalin.marinas@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox