This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

jffs2 inconsistent lock state

Hey all,

 

I'm running my root filesystem out of nand using jffs2. while trying to write to the filesystem using the PSP kernel, i get this:

 

[   83.246887]
[   83.246887] =================================
[   83.252777] [ INFO: inconsistent lock state ]
[   83.257171] 2.6.32-14968-gdd1e7a5-dirty #173
[   83.261474] ---------------------------------
[   83.265838] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[   83.272430] cp/1735 [HC0[0]:SC0[0]:HE1:SE1] takes:
[   83.277252]  (&f->sem){+.+.?.}, at: [<c0191b58>] jffs2_do_clear_inode+0x20/0c
[   83.284759] {RECLAIM_FS-ON-W} state was registered at:
[   83.289916]   [<c0090ce0>] mark_held_locks+0x44/0x7c
[   83.294952]   [<c0090dd4>] lockdep_trace_alloc+0xbc/0xec
[   83.300323]   [<c00de780>] kmem_cache_alloc+0x24/0x128
[   83.305511]   [<c0193d5c>] jffs2_do_read_inode+0x13c/0x20c
[   83.311035]   [<c019a758>] jffs2_iget+0x70/0x324
[   83.315704]   [<c019ac88>] jffs2_do_fill_super+0x14c/0x21c
[   83.321228]   [<c02647f0>] get_sb_mtd_aux+0x54/0xb0
[   83.326171]   [<c0264a08>] get_sb_mtd+0x164/0x194
[   83.330932]   [<c019b6ec>] jffs2_get_sb+0x18/0x20
[   83.335662]   [<c00e326c>] vfs_kern_mount+0x90/0x154
[   83.340698]   [<c00e3374>] do_kern_mount+0x34/0xd8
[   83.345520]   [<c00f8998>] do_mount+0x678/0x6dc
[   83.350097]   [<c00f8a80>] sys_mount+0x84/0xc4
[   83.354583]   [<c0034940>] ret_fast_syscall+0x0/0x38
[   83.359619] irq event stamp: 766128
[   83.363128] hardirqs last  enabled at (766128): [<c00bcf38>] free_hot_cold_p8
[   83.371551] hardirqs last disabled at (766127): [<c00bcdf4>] free_hot_cold_p8
[   83.379882] softirqs last  enabled at (764017): [<c006cf04>] irq_exit+0x50/0c
[   83.387268] softirqs last disabled at (763998): [<c006cf04>] irq_exit+0x50/0c
[   83.394622]
[   83.394622] other info that might help us debug this:
[   83.401214] 2 locks held by cp/1735:
[   83.404815]  #0:  (shrinker_rwsem){++++..}, at: [<c00c3198>] shrink_slab+0x28
[   83.412567]  #1:  (iprune_sem){.+.+.-}, at: [<c00f3de8>] shrink_icache_memor8
[   83.420776]
[   83.420776] stack backtrace:
[   83.425170] [<c003a61c>] (unwind_backtrace+0x0/0xdc) from [<c0090630>] (prin)
[   83.434387] [<c0090630>] (print_usage_bug+0x170/0x1b4) from [<c00909d0>] (ma)
[   83.443237] [<c00909d0>] (mark_lock+0x35c/0x628) from [<c0092350>] (__lock_a)
[   83.452087] [<c0092350>] (__lock_acquire+0x6d8/0x173c) from [<c009348c>] (lo)
[   83.461059] [<c009348c>] (lock_acquire+0xd8/0xf0) from [<c04467c0>] (mutex_l)
[   83.470092] [<c04467c0>] (mutex_lock_nested+0x60/0x2e4) from [<c0191b58>] (j)
[   83.479919] [<c0191b58>] (jffs2_do_clear_inode+0x20/0x10c) from [<c00f3ab8>])
[   83.489105] [<c00f3ab8>] (clear_inode+0x9c/0xfc) from [<c00f3d10>] (dispose_)
[   83.497619] [<c00f3d10>] (dispose_list+0x58/0x100) from [<c00f3fbc>] (shrink)
[   83.507080] [<c00f3fbc>] (shrink_icache_memory+0x204/0x248) from [<c00c3248>)
[   83.516448] [<c00c3248>] (shrink_slab+0xd4/0x178) from [<c00c3afc>] (try_to_)
[   83.525573] [<c00c3afc>] (try_to_free_pages+0x1c8/0x2dc) from [<c00bd444>] ()
[   83.535736] [<c00bd444>] (__alloc_pages_nodemask+0x32c/0x56c) from [<c00beee)
[   83.546539] [<c00beeec>] (__do_page_cache_readahead+0xd8/0x22c) from [<c00bf)
[   83.555999] [<c00bf060>] (ra_submit+0x20/0x24) from [<c00b93ec>] (generic_fi)
[   83.565185] [<c00b93ec>] (generic_file_aio_read+0x298/0x694) from [<c00e0d40)
[   83.574645] [<c00e0d40>] (do_sync_read+0xac/0xfc) from [<c00e1758>] (vfs_rea)
[   83.582824] [<c00e1758>] (vfs_read+0xa8/0xd0) from [<c00e182c>] (sys_read+0x)
[   83.590606] [<c00e182c>] (sys_read+0x3c/0x68) from [<c0034940>] (ret_fast_sy)

 

Is this a cause for concern? it otherwise seems to work. Has anyone seen this with the 3.0.1.06 PSP release before?