JFFS2 locking issue on 3.14 + patches

[Michal Simek]

On 04/29/2014 07:05 PM, Brian Norris wrote:
> + Artem
> 
> On Tue, Apr 29, 2014 at 02:02:07PM +0200, Michal Simek wrote:
>> On 04/28/2014 06:51 PM, Brian Norris wrote:
>>> On Mon, Apr 28, 2014 at 05:57:12PM +0200, Michal Simek wrote:
>>>> we are having this problem with JFFS2 rootfs. It is v3.14 kernel
>>>> with these 5 patches which cherry-picked from 3.15.
>>>>
>>>> 41bf1a2 jffs2: Fix crash due to truncation of csize
>>>> 3367da5 jffs2: Fix segmentation fault found in stress test
>>>> 01887a3 jffs2: unlock f->sem on error in jffs2_new_inode()
>>>> 13b546d jffs2: avoid soft-lockup in jffs2_reserve_space_gc()
>>>> 3ead957 jffs2: remove from wait queue after schedule()
>>>
>>> Have you bisected these? And possibly test the patches in isolation
>>> (there are only 5)?
> [...]
>> Bisecting these five patches don't solve anything.
> 
> BTW, for your bisecting, did you have a clean version of your
> filesystem? After a bug creates CRC / data errors, it's possible
> that--no matter what kernel you boot--you will retain those errors on
> your flash media.

I didn't see any problem like this. It means filesystem
is not corrupted when CRC problem happen.


>> Locking issue was introduced 3.6-rc3 by this commit.
>> I will check CONFIG_JFFS2_FS_WRITEBUFFER option.
> 
> Sorry, I think I misread your first report; your problem is probably not
> with any of these 5 patches, but with some other yet-unsolved issue.

Yes that's my impression too.

>> commit a445f784ae5558a3da680aa6b39ed53c95a551c1
>> Author: Artem Bityutskiy <artem.bityutskiy at linux.intel.com>
>> Date:   Thu Aug 23 10:10:07 2012 +0300
>>
>>     JFFS2: fix unmount regression
>>
>>     This patch fixes regression introduced by
>>     "8bdc81c jffs2: get rid of jffs2_sync_super". We submit a delayed work in order
>>     to make sure the write-buffer is synchronized at some point. But we do not
>>     flush it when we unmount, which causes an oops when we unmount the file-system
>>     and then the delayed work is executed.
>>
>>     This patch fixes the issue by adding a "cancel_delayed_work_sync()" infocation
>>     in the '->sync_fs()' handler. This will make sure the delayed work is canceled
>>     on sync, unmount and re-mount. And because VFS always callse 'sync_fs()' before
>>     unmounting or remounting, this fixes the issue.
>>
>>     Reported-by: Ludovic Desroches <ludovic.desroches at atmel.com>
>>     Cc: stable at vger.kernel.org [3.5+]
>>     Signed-off-by: Artem Bityutskiy <artem.bityutskiy at linux.intel.com>
>>     Tested-by: Ludovic Desroches <ludovic.desroches at atmel.com>
>>     Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
> 
> Bisection turned you up here?

I have looked at it more and JFFS2_FS_WRITEBUFFER is broken from this commit.
When you disable it is working till this commit on Microblaze.

commit ac093f8d5e76be1f2654acfd7a59d339ba037654
Author:     Michael S. Tsirkin <mst at redhat.com>

    microblaze: uaccess s/might_sleep/might_fault/

And surprisingly the same change is causing problem on ARM.

commit ad72907acd2943304c292ae36960bb66e6dc23c9
Author:     Will Deacon <will.deacon at arm.com>

    ARM: 7528/1: uaccess: annotate [__]{get,put}_user functions with might_fault()


I have revert these 2 patches and disable JFFS2_FS_WRITEBUFFER
on the top of that 5 patches and everything seems to work.

Then I have tried to disable debug locking features which I have ON
and I have ended up that disabling CONFIG_PROVE_LOCKING
and CRC problem is back again.


> Honestly, I'm not too familiar with JFFS2. Maybe Artem can comment,
> since he authored this commit.

Is someone doing any testing on JFFS2 at all?
From this debugging it looks like that JFFS2 have some serious issues
for quite a long time.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20140430/30668349/attachment.sig>