From patchwork Fri Jul 24 10:49:09 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adrian Hunter X-Patchwork-Id: 30198 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bilbo.ozlabs.org (Postfix) with ESMTPS id DFE3FB7257 for ; Fri, 24 Jul 2009 20:51:05 +1000 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1MUIKg-0002c1-Q0; Fri, 24 Jul 2009 10:48:58 +0000 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by bombadil.infradead.org with esmtps (Exim 4.69 #1 (Red Hat Linux)) id 1MUIKX-0002ZW-RB for linux-mtd@lists.infradead.org; Fri, 24 Jul 2009 10:48:54 +0000 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n6OAmDR5007549; Fri, 24 Jul 2009 05:48:33 -0500 Received: from vaepf101.NOE.Nokia.com ([10.160.244.86]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 13:48:35 +0300 Received: from [172.21.41.56] ([172.21.41.56]) by vaepf101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 13:48:34 +0300 Message-ID: <4A6991A5.4020105@nokia.com> Date: Fri, 24 Jul 2009 13:49:09 +0300 From: Adrian Hunter User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Daniel Mack Subject: Re: ubifs: error unwinding trouble References: <20090724103038.GN19257@buzzloop.caiaq.de> In-Reply-To: <20090724103038.GN19257@buzzloop.caiaq.de> X-OriginalArrivalTime: 24 Jul 2009 10:48:34.0732 (UTC) FILETIME=[4AE91EC0:01CA0C4C] X-Nokia-AV: Clean X-Spam-Score: -4.0 (----) X-Spam-Report: SpamAssassin version 3.2.5 on bombadil.infradead.org summary: Content analysis details: (-4.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -4.0 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [192.100.105.134 listed in list.dnswl.org] Cc: "Bityutskiy Artem \(Nokia-M/Helsinki\)" , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Adrian Hunter X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Daniel Mack wrote: > On a recent git kernel, the error unwinding for UBIFS seems to have some > problem, most probably a double-free or something similar. > > When UBI is pointed to the right mtd partition (using command line > arguments) , everything is fine. But when it's (accidentionally) set to > some very small mtd, the attach process fails. Which wouldn't be a bad > thing by itself, but it somehow messes up the slub/slab allocators then > which causes very strange memory corruption effects - see the backtrace > below. > > The Ooops itself is unreleated to UBI, but it does not occur when UBI > succeeds in attaching the volume. > > Any idea? I searched for awhile but couldn't see anything obvious. Looks like a double free of the eba_tbl This might help: diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c index 0f2034c..e4d9ef0 100644 --- a/drivers/mtd/ubi/eba.c +++ b/drivers/mtd/ubi/eba.c @@ -1254,6 +1254,7 @@ out_free: if (!ubi->volumes[i]) continue; kfree(ubi->volumes[i]->eba_tbl); + ubi->volumes[i]->eba_tbl = NULL; } return err; }