Hello, The kernel sometimes prints the stacktrace at the end of this email when unmounting a squashfs filesystem. I'm using squashfs on top of a (work in progress) UBI->block layer. See https://lkml.org/lkml/2011/9/12/41 . However, the stacktrace does not show any part of ubiblk. I'm running 3.1-rc2 with changes only in drivers/mtd/ubi I can't voluntarily reproduce it: to the best of my knowledge, the conditions are the same when it happens and when it does not. Plus, it happens very rarely. [ 312.091735] ============================================= [ 312.098968] [ INFO: possible recursive locking detected ] [ 312.104644] 3.1.0-rc2-igepv2-00003-g15ad483-dirty #91 [ 312.109954] --------------------------------------------- [ 312.115631] umount/384 is trying to acquire lock: [ 312.120544] (&(&parent->list_lock)->rlock){-.-...}, at: [<c00c29e4>] cache_flusharray+0x24/0xa8 [ 312.129821] [ 312.129821] but task is already holding lock: [ 312.135925] (&(&parent->list_lock)->rlock){-.-...}, at: [<c00c29e4>] cache_flusharray+0x24/0xa8 [ 312.145172] [ 312.145172] other info that might help us debug this: [ 312.152008] Possible unsafe locking scenario: [ 312.152008] [ 312.158233] CPU0 [ 312.160797] ---- [ 312.163330] lock(&(&parent->list_lock)->rlock); [ 312.168273] lock(&(&parent->list_lock)->rlock); [ 312.173217] [ 312.173217] *** DEADLOCK *** [ 312.173248] [ 312.179443] May be due to missing lock nesting notation [ 312.179443] [ 312.186553] 2 locks held by umount/384: [ 312.190582] #0: (&type->s_umount_key#27){+.+...}, at: [<c00c983c>] deactivate_super+0x58/0x64 [ 312.199737] #1: (&(&parent->list_lock)->rlock){-.-...}, at: [<c00c29e4>] cache_flusharray+0x24/0xa8 [ 312.209411] [ 312.209411] stack backtrace: [ 312.214019] [<c001abfc>] (unwind_backtrace+0x0/0x128) from [<c0079998>] (__lock_acquire+0x1880/0x1908) [ 312.223785] [<c0079998>] (__lock_acquire+0x1880/0x1908) from [<c0079edc>] (lock_acquire+0x60/0x74) [ 312.233215] [<c0079edc>] (lock_acquire+0x60/0x74) from [<c03c3be8>] (_raw_spin_lock+0x2c/0x3c) [ 312.242248] [<c03c3be8>] (_raw_spin_lock+0x2c/0x3c) from [<c00c29e4>] (cache_flusharray+0x24/0xa8) [ 312.251647] [<c00c29e4>] (cache_flusharray+0x24/0xa8) from [<c00c2bb8>] (kmem_cache_free+0x64/0x98) [ 312.261138] [<c00c2bb8>] (kmem_cache_free+0x64/0x98) from [<c00c2d40>] (free_block+0xf4/0x140) [ 312.270202] [<c00c2d40>] (free_block+0xf4/0x140) from [<c00c2a3c>] (cache_flusharray+0x7c/0xa8) [ 312.279327] [<c00c2a3c>] (cache_flusharray+0x7c/0xa8) from [<c00c2b1c>] (kfree+0xb4/0xec) [ 312.287933] [<c00c2b1c>] (kfree+0xb4/0xec) from [<bf0206c4>] (squashfs_cache_delete+0x40/0x88 [squashfs]) [ 312.298004] [<bf0206c4>] (squashfs_cache_delete+0x40/0x88 [squashfs]) from [<bf023374>] (squashfs_put_super+0x2c/0x80 [squashfs]) [ 312.310211] [<bf023374>] (squashfs_put_super+0x2c/0x80 [squashfs]) from [<c00c89f8>] (generic_shutdown_super+0x58/0xb0) [ 312.321533] [<c00c89f8>] (generic_shutdown_super+0x58/0xb0) from [<c00c8a68>] (kill_block_super+0x18/0x68) [ 312.331665] [<c00c8a68>] (kill_block_super+0x18/0x68) from [<c00c8cfc>] (deactivate_locked_super+0x40/0x6c) [ 312.341888] [<c00c8cfc>] (deactivate_locked_super+0x40/0x6c) from [<c00e1e9c>] (sys_umount+0x2f8/0x324) [ 312.351776] [<c00e1e9c>] (sys_umount+0x2f8/0x324) from [<c0013c00>] (ret_fast_syscall+0x0/0x3c) Regards, David Wagner -- David Wagner, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
