UBIFS oops after remount ro

[Artem Bityutskiy]

On Mon, 2010-11-29 at 14:18 +0100, Wolfgang Wegner wrote:
> Hi Artem,
> 
> I can now reproduce the Oops with CONFIG_UBIFS_FS_DEBUG and your
> patch.

OK, I thought one of ubi_asserts() would trigger. They do not.

>  However, I had to manually apply the hunks because my tree
> seems to differ enough for patch to not apply it automatically...

I sent the patch against the ubifs-v2.6.32 tree, which has all the UBIFS
patches back-ported, and which I recommend to use:

http://linux-mtd.infradead.org/doc/ubifs.html#L_source

(hmm, need to update that page, now there are more back-port trees)

> And here is the complete console log in case I missed some
> important information:

Well, because of the ps output, it is difficult to read kernel prints.
Also, the situation becomes more difficult because you have several
UBIFS file-systems, so many messages are irrelevant. Would be nice to
print them only for the instance which oopses.

> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs
> qqq: kupdated for ubifs

So, not 100% sure, but probably this is kuptdated writeback. For some
reason mm thinks ubifs has dirty data, although it should not have,
because re-mounting path has full sync.

> qqq: writing inode 3298

Does this always happen for inode 3298? Or the inode number changes?

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)