random squashfs bug at unmount

[David Wagner <david.wagner@free-electrons.com>]

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