Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754958AbZINDSF (ORCPT ); Sun, 13 Sep 2009 23:18:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752798AbZINDSE (ORCPT ); Sun, 13 Sep 2009 23:18:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33494 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbZINDSD (ORCPT ); Sun, 13 Sep 2009 23:18:03 -0400 Message-ID: <4AADB5EE.9090902@redhat.com> Date: Mon, 14 Sep 2009 11:18:06 +0800 From: Danny Feng User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: Eric Paris CC: cl@linux-foundation.org, penberg@cs.helsinki.fi, mingo@elte.hu, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [GIT BISECT] BUG kmalloc-8192: Object already free from kmem_cache_destroy References: <1252866835.13780.37.camel@dhcp231-106.rdu.redhat.com> In-Reply-To: <1252866835.13780.37.camel@dhcp231-106.rdu.redhat.com> Content-Type: multipart/mixed; boundary="------------040408020607040807040307" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5620 Lines: 133 This is a multi-part message in MIME format. --------------040408020607040807040307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 09/14/2009 02:33 AM, Eric Paris wrote: > 2a38a002fbee06556489091c30b04746222167e4 is first bad commit > commit 2a38a002fbee06556489091c30b04746222167e4 > Author: Xiaotian Feng > 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 > Signed-off-by: Xiaotian Feng > Signed-off-by: Pekka Enberg > > CONFIG_SLUB_DEBUG=y > CONFIG_SLUB=y > CONFIG_SLUB_DEBUG_ON=y > # CONFIG_SLUB_STATS is not set > > I created a very simple kernel module which consisted only of: > > static int __init kmem_cache_test_init_module(void) > { > struct kmem_cache *test_cachep; > > test_cachep = kmem_cache_create("test_cachep", 32, 0, 0, NULL); > if (test_cachep) > kmem_cache_destroy(test_cachep); > > return 0; > } > > Before this patch it works just fine. After this patch I get a bug like > this: > > [ 59.921431] kmem_cache_test_init_module: > [ 59.922415] ============================================================================= > [ 59.922418] BUG kmalloc-8192: Object already free > [ 59.922419] ----------------------------------------------------------------------------- > [ 59.922420] > [ 59.922453] INFO: Allocated in kmem_cache_create+0x70/0x320 age=1 cpu=3 pid=1781 > [ 59.922458] INFO: Freed in kmem_cache_release+0x23/0x40 age=0 cpu=3 pid=1781 > [ 59.922461] INFO: Slab 0xffffea0000373cc0 objects=3 used=1 fp=0xffff8800087fa048 flags=0x200000000040c3 > [ 59.922463] INFO: Object 0xffff8800087fa048 @offset=8264 fp=0xffff8800087fc090 > [ 59.922463] > [ 59.922465] Bytes b4 0xffff8800087fa038: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ > [ 59.922477] Object 0xffff8800087fa048: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > [ 59.922487] Object 0xffff8800087fa058: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > [snip] > [ 59.923261] Object 0xffff8800087fb028: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > [ 59.923261] Object 0xffff8800087fb038: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk > [ 59.923261] Redzone 0xffff8800087fc048: bb bb bb bb bb bb bb bb »»»»»»»» > [ 59.923261] Padding 0xffff8800087fc088: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ > [ 59.923261] Pid: 1781, comm: insmod Not tainted 2.6.31-rc2 #33 > [ 59.923261] Call Trace: > [ 59.923261] [] print_trailer+0xfb/0x160 > [ 59.923261] [] object_err+0x49/0x70 > [ 59.923261] [] __slab_free+0x266/0x3c0 > [ 59.923261] [] kfree+0xec/0x220 > [ 59.923261] [] ? kmem_cache_destroy+0x20e/0x230 > [ 59.923261] [] ? kmem_cache_test_init_module+0x0/0x67 [cache_test] > [ 59.923261] [] ? kmem_cache_test_init_module+0x0/0x67 [cache_test] > [ 59.923261] [] kmem_cache_destroy+0x20e/0x230 > [ 59.923261] [] ? kmem_cache_test_init_module+0x0/0x67 [cache_test] > [ 59.923261] [] kmem_cache_test_init_module+0x4f/0x67 [cache_test] > [ 59.923261] [] do_one_initcall+0x4b/0x1a0 > [ 59.923261] [] sys_init_module+0x108/0x260 > [ 59.923261] [] system_call_fastpath+0x16/0x1b > [ 59.923261] FIX kmalloc-8192: Object at 0xffff8800087fa048 not freed > > I think I got the real problem, that's introduced from former commit a0e1d1be204612ee83b3afe8aa24c5d27e63d464, this results kmem_cache always be freed at kmem_cache_create.... Can following patch fix this issue? --------------040408020607040807040307 Content-Type: text/x-patch; name="0001-slub-fix-kmem_cache-wrongly-freed-in-kmem_cache_cre.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-slub-fix-kmem_cache-wrongly-freed-in-kmem_cache_cre.pat"; filename*1="ch" >From f5a04f3db3adaa605e951ae9f46708da63979bda Mon Sep 17 00:00:00 2001 From: Xiaotian Feng Date: Mon, 14 Sep 2009 11:12:27 +0800 Subject: [PATCH] slub: fix kmem_cache wrongly freed in kmem_cache_create commit a0e1d1b move sysfs operations outside of slub_lock, but wrongly freed kmem_cache in any cases (should only free kmem_cache when open failed). Signed-off-by: Xiaotian Feng --- mm/slub.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index b627675..40e12d5 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3337,8 +3337,8 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size, goto err; } return s; - } - kfree(s); + } else + kfree(s); } up_write(&slub_lock); -- 1.6.2.5 --------------040408020607040807040307-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/