[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1252883493.16335.8.camel@dhcp231-106.rdu.redhat.com>
Date: Sun, 13 Sep 2009 19:11:33 -0400
From: Eric Paris <eparis@...hat.com>
To: cl@...ux-foundation.org
Cc: dfeng@...hat.com, penberg@...helsinki.fi, mingo@...e.hu,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [GIT BISECT] BUG kmalloc-8192: Object already free from
kmem_cache_destroy
On Sun, 2009-09-13 at 14:33 -0400, Eric Paris wrote:
> 2a38a002fbee06556489091c30b04746222167e4 is first bad commit
> commit 2a38a002fbee06556489091c30b04746222167e4
> Author: Xiaotian Feng <dfeng@...hat.com>
> Date: Wed Jul 22 17:03:57 2009 +0800
>
> slub: sysfs_slab_remove should free kmem_cache when debug is enabled
>
> kmem_cache_destroy use sysfs_slab_remove to release the kmem_cache,
> but when CONFIG_SLUB_DEBUG is enabled, sysfs_slab_remove just release
> related kobject, the whole kmem_cache is missed to release and cause
> a memory leak.
>
> Acked-by: Christoph Lameer <cl@...ux-foundation.org>
> Signed-off-by: Xiaotian Feng <dfeng@...hat.com>
> Signed-off-by: Pekka Enberg <penberg@...helsinki.fi>
>
> CONFIG_SLUB_DEBUG=y
> CONFIG_SLUB=y
> CONFIG_SLUB_DEBUG_ON=y
> # CONFIG_SLUB_STATS is not set
I also had problems destroying a kmem_cache in a security_initcall()
function which had a different backtrace (it's what made me create the
module and bisect.) So be sure to let me know what you find so I can
be sure that we fix that place as well (I believe that was a kref
problem rather than a double free)
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists