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)? From top to down - reverts on the top of these 5 patches. HEAD: Locking issue I have sent in origin email and CRC problems Reverting 41bf1a2 jffs2: Fix crash due to truncation of csize Generates a lot of warnings like this. [ 6.250541] jffs2: warning: (682) jffs2_get_inode_nodes: Eep. No valid nodes for ino #261. [ 6.258732] jffs2: warning: (682) jffs2_do_read_inode_internal: no data nodes found for ino #261 Reverting one patch 3367da5 jffs2: Fix segmentation fault found in stress test on the top of 5 patches - lock issue is present but CRC issue is gone on uniprocessor system. CRC issue is present on SMP case Reverting two patches 3367da5 jffs2: Fix segmentation fault found in stress test 01887a3 jffs2: unlock f->sem on error in jffs2_new_inode() on the top of 5 patches - only locking issue is reported, CRC issue is gone on uniprocessor system Reverting 3 patches 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() on the top of 5 patches - locking issue still present with CRC issue again and data problems. [ 18.959144] jffs2: notice: (630) check_node_data: wrong data CRC in data node at 0x0015348c: read 0x8fb195d5, calculated 0xbc622daa. [ 18.971009] jffs2: warning: (630) jffs2_do_read_inode_internal: no data nodes found for ino #392 [ 18.979766] jffs2: Returned error for crccheck of ino #392. Expect badness... [ 39.152478] jffs2: notice: (630) check_node_data: wrong data CRC in data node at 0x00492cd8: read 0xe62c6036, calculated 0xf875522b. [ 39.167465] jffs2: warning: (630) jffs2_do_read_inode_internal: Truncating ino #822 to 41568 bytes failed because it only had 40960 bytes to start with! Reverting 3 patches 3367da5 jffs2: Fix segmentation fault found in stress test 01887a3 jffs2: unlock f->sem on error in jffs2_new_inode() 3ead957 jffs2: remove from wait queue after schedule() on the top of 5 patches - locking issue still present with CRC issue again and data problems. Origin testing was done on zynq with qspi and I have also retest it on microblaze and NOR flash and issue is just there. Bisecting these five patches don't solve anything. Locking issue was introduced 3.6-rc3 by this commit. I will check CONFIG_JFFS2_FS_WRITEBUFFER option. commit a445f784ae5558a3da680aa6b39ed53c95a551c1 Author: Artem Bityutskiy 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 Cc: stable@vger.kernel.org [3.5+] Signed-off-by: Artem Bityutskiy Tested-by: Ludovic Desroches Signed-off-by: David Woodhouse 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