MTD : Kernel oops when remounting ubifs as read/write

[Artem Bityutskiy]

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 <artem.bityutskiy at linux.intel.com>
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 <artem.bityutskiy at linux.intel.com>
Reported-by: Mark Jackson <mpfj-list at mimc.co.uk>
Cc: stable at 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

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-UBIFS-make-space-fixup-work-in-the-remount-case.patch
Type: text/x-patch
Size: 2245 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130314/c6ec3b82/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reproduce.sh
Type: application/x-shellscript
Size: 472 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130314/c6ec3b82/attachment-0001.bin>
-------------- next part --------------
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=200MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize