From patchwork Thu Mar 14 09:13:45 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 227514 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 951512C0087 for ; Thu, 14 Mar 2013 20:14:52 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UG4E1-0007ea-9N; Thu, 14 Mar 2013 09:13:25 +0000 Received: from mga03.intel.com ([143.182.124.21]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UG4Dq-0007bw-B2 for linux-mtd@lists.infradead.org; Thu, 14 Mar 2013 09:13:21 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 14 Mar 2013 02:12:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,843,1355126400"; d="cfg'?sh'?scan'208,223";a="270604223" Received: from linux.jf.intel.com (HELO linux.intel.com) ([10.23.219.25]) by azsmga001.ch.intel.com with ESMTP; 14 Mar 2013 02:12:50 -0700 Received: from [10.237.72.90] (unknown [10.237.72.90]) by linux.intel.com (Postfix) with ESMTP id 350A26A4009; Thu, 14 Mar 2013 02:12:43 -0700 (PDT) Message-ID: <1363252425.11441.94.camel@sauron.fi.intel.com> Subject: Re: MTD : Kernel oops when remounting ubifs as read/write From: Artem Bityutskiy To: Mark Jackson Date: Thu, 14 Mar 2013 11:13:45 +0200 In-Reply-To: <51405F3A.3090901@mimc.co.uk> References: <5134CEF9.5070502@mimc.co.uk> <1363087506.3348.62.camel@sauron.fi.intel.com> <51405F3A.3090901@mimc.co.uk> X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130314_051314_733839_BE567752 X-CRM114-Status: GOOD ( 27.78 ) X-Spam-Score: -5.0 (-----) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-5.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [143.182.124.21 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dedekind1[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 0.8 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dedekind1[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.9 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list Cc: "linux-omap@vger.kernel.org" , "linux-mtd@lists.infradead.org" , lkml , adrian.hunter@intel.com X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Wed, 2013-03-13 at 11:12 +0000, Mark Jackson wrote: > Sorry ... this just locks up the unit. OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details below. The patch I proposed did not get the error path correctly, but it does fix the issue. I think what you treat as "lockup" is the fixup process. UBIFS basically reads the entire UBI volume and writes it back. And it uses the atomic change UBI service, which means it also calculates CRC of everything it writes. And this all just takes a lot of time. This has to be done only once on the first mount. I've attached the following: 1. The patch which fixes the issue when I use nandsim. It is also inlined in the end. Please, give it a try and be more patient - wait longer. Please, do report your results back. 2. 'reproduce.sh' - a quick and dirty shell script which reproduces the problem 3. ubinize.cfg - is needed for 'reproduce.sh'. Thanks! From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 14 Mar 2013 10:49:23 +0200 Subject: [PATCH] UBIFS: make space fixup work in the remount case The UBIFS space fixup is a useful feature which allows to fixup the "broken" flash space at the time of the first mount. The "broken" space is usually the result of using a "dumb" industrial flasher which is not able to skip empty NAND pages and just writes all 0xFFs to the empty space, which has grave side-effects for UBIFS when UBIFS trise to write useful data to those empty pages. The fix-up feature works roughly like this: 1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image (see -F option) 2. when the file-system is mounted for the first time, UBIFS notices the fixup flag and re-writes the entire media atomically, which may take really a lot of time. 3. UBIFS clears the fixup flag in the superblock. This works fine when the file system is mounted R/W for the very first time. But it did not really work in the case when we first mount the file-system R/O, and then re-mount R/W. The reason was that we started the fixup procedure too late, which we cannot really do because we have to fixup the space before it starts being used. Signed-off-by: Artem Bityutskiy Reported-by: Mark Jackson Cc: stable@vger.kernel.org # 3.0+ --- fs/ubifs/super.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 14 Mar 2013 10:49:23 +0200 Subject: [PATCH] UBIFS: make space fixup work in the remount case The UBIFS space fixup is a useful feature which allows to fixup the "broken" flash space at the time of the first mount. The "broken" space is usually the result of using a "dumb" industrial flasher which is not able to skip empty NAND pages and just writes all 0xFFs to the empty space, which has grave side-effects for UBIFS when UBIFS trise to write useful data to those empty pages. The fix-up feature works roughly like this: 1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image (see -F option) 2. when the file-system is mounted for the first time, UBIFS notices the fixup flag and re-writes the entire media atomically, which may take really a lot of time. 3. UBIFS clears the fixup flag in the superblock. This works fine when the file system is mounted R/W for the very first time. But it did not really work in the case when we first mount the file-system R/O, and then re-mount R/W. The reason was that we started the fixup procedure too late, which we cannot really do because we have to fixup the space before it starts being used. Signed-off-by: Artem Bityutskiy Cc: stable@vger.kernel.org # 3.0+ --- fs/ubifs/super.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index ac838b8..fa4aec6 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -1568,10 +1568,17 @@ static int ubifs_remount_rw(struct ubifs_info *c) c->remounting_rw = 1; c->ro_mount = 0; + if (c->space_fixup) { + err = ubifs_fixup_free_space(c); + if (err) + return err; + } + err = check_free_space(c); if (err) goto out; + if (c->old_leb_cnt != c->leb_cnt) { struct ubifs_sb_node *sup; @@ -1684,12 +1691,6 @@ static int ubifs_remount_rw(struct ubifs_info *c) err = dbg_check_space_info(c); } - if (c->space_fixup) { - err = ubifs_fixup_free_space(c); - if (err) - goto out; - } - mutex_unlock(&c->umount_mutex); return err; -- 1.7.7.6