From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265102AbUHHGH6 (ORCPT ); Sun, 8 Aug 2004 02:07:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265195AbUHHGH6 (ORCPT ); Sun, 8 Aug 2004 02:07:58 -0400 Received: from [61.155.114.21] ([61.155.114.21]:56843 "EHLO mail.mobilesoft.com.cn") by vger.kernel.org with ESMTP id S265102AbUHHGHr (ORCPT ); Sun, 8 Aug 2004 02:07:47 -0400 Date: Sun, 8 Aug 2004 14:12:06 +0800 From: Wu Jian Feng To: Linux Kernel List , linux-mtd@lists.infradead.org Cc: Russell King Subject: Re: [BUG] 2.6.8-rc3 slab corruption (jffs2?) Message-ID: <20040808061206.GA5417@mobilesoft.com.cn> Mail-Followup-To: Linux Kernel List , linux-mtd@lists.infradead.org, Russell King References: <20040807150458.E2805@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040807150458.E2805@flint.arm.linux.org.uk> User-Agent: Mutt/1.5.6+20040803i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Can't figure out why but have a quick workaround for this: --- a/fs/jffs2/erase.c 2004-08-08 14:03:06.000000000 +0800 +++ b/fs/jffs2/erase.c 2004-08-08 14:05:41.000000000 +0800 @@ -72,8 +72,10 @@ ((struct erase_priv_struct *)instr->priv)->c = c; ret = c->mtd->erase(c->mtd, instr); - if (!ret) + if (!ret) { + kfree(instr); return; + } bad_offset = instr->fail_addr; kfree(instr); @@ -206,7 +208,6 @@ } else { jffs2_erase_succeeded(priv->c, priv->jeb); } - kfree(instr); } #endif /* !__ECOS */ On Sat, Aug 07, 2004 at 03:04:58PM +0100, Russell King wrote: > Not sure exactly what caused this, but it happened while logging in > (after fixing the previous two reported problems - the first by backing > out the last change to redboot.c and the second by commenting out > ri->usercompr in fs/jffs2/read.c.) > > Slab corruption: start=c1e39474, len=64 > Redzone: 0x5a2cf071/0x5a2cf071. > Last user: [](cfi_intelext_erase_varsize+0x58/0x64) > 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 4f 6b > Prev obj: start=c1e39428, len=64 > Redzone: 0x5a2cf071/0x5a2cf071. > Last user: [](jffs2_garbage_collect_deletion_dirent+0x80/0x8c) > 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > Next obj: start=c1e394c0, len=64 > Redzone: 0x170fc2a5/0x170fc2a5. > Last user: [](neigh_hh_init+0x64/0x11c) > 000: 00 00 00 00 03 00 00 00 08 00 00 00 0e 00 00 00 > 010: 00 b0 34 c0 00 00 08 00 2b 95 1d 7b 00 c0 1b 00 > > Due to tail call optimisation, its difficult to work out exactly what's > going on, but the first seems to be a kfree call from the erase callback > (possibly jffs2_erase_callback). The second function is the call to > jffs2_free_full_dirent() in jffs2_garbage_collect_deletion_dirent(). > > Any ideas? I haven't been able to reproduce (presumably because the > erase succeeded, and we didn't need to re-erase again.) > > -- > Russell King > Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ > maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ > 2.6 Serial core > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/