Lockdep report against pktcdvd

From: Blaisorblade
Date: Fri Mar 09 2007 - 17:10:45 EST


When booting my laptop with a 2.6.20.1 laptop with lockdep enabled to test my
code, I got a lockdep warning on pktcdvd on setup. It seems that do_open on a
pktcdvd device causes another do_open on the underlying device, and that
mutex_lock_nested is called with the same subclass (the for_part argument to
do_open). So this may be a false positive, after all, but I'll let you
decide.

I've installed and configured Ubuntu udftools so that pktcdvd0 is linked
to /dev/cdrw, i.e. /dev/sr0, on my system.

This is an extract from my /proc/config.gz - it shows that both LOCKDEP and
FRAME_POINTER are enabled, so the stack trace below out to be correct.

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
CONFIG_FRAME_POINTER=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_STACKOVERFLOW=y
~

[ Â 56.517353] pktcdvd: writer pktcdvd0 mapped to sr0
[ Â 56.525469]
[ Â 56.525471] =============================================
[ Â 56.525476] [ INFO: possible recursive locking detected ]
[ Â 56.525479] 2.6.20.1-rfp+skas-v9-pre9+skas-dbg #3
[ Â 56.525498] ---------------------------------------------
[ Â 56.525501] vol_id/4536 is trying to acquire lock:
[ Â 56.525503] Â(&bdev->bd_mutex){--..}, at: [<ffffffff810a2869>]
do_open+0x7b/0x2c4
[ Â 56.525515]
[ Â 56.525521] but task is already holding lock:
[ Â 56.525536] Â(&bdev->bd_mutex){--..}, at: [<ffffffff810a2869>]
do_open+0x7b/0x2c4
[ Â 56.525560]
[ Â 56.525561] other info that might help us debug this:
[ Â 56.525579] 2 locks held by vol_id/4536:
[ Â 56.525593] Â#0: Â(&bdev->bd_mutex){--..}, at: [<ffffffff810a2869>]
do_open+0x7b/0x2c4
[ Â 56.525610] Â#1: Â(&ctl_mutex#2){--..}, at: [<ffffffff8120d470>]
mutex_lock+0x22/0x26
[ Â 56.525634]
[ Â 56.525634] stack backtrace:
[ Â 56.525646]
[ Â 56.525652] Call Trace:
[ Â 56.525666] Â[<ffffffff8104aa1e>] __lock_acquire+0x137/0xa62
[ Â 56.525687] Â[<ffffffff8120ce13>] __mutex_unlock_slowpath+0x129/0x14f
[ Â 56.525712] Â[<ffffffff8104b61c>] lock_acquire+0x4d/0x69
[ Â 56.525732] Â[<ffffffff810a2869>] do_open+0x7b/0x2c4
[ Â 56.525750] Â[<ffffffff8120d57a>] mutex_lock_nested+0x106/0x2cd
[ Â 56.525774] Â[<ffffffff810a2869>] do_open+0x7b/0x2c4
[ Â 56.525795] Â[<ffffffff810a2b98>] __blkdev_get+0x7b/0x8d
[ Â 56.525830] Â[<ffffffff810a2bb5>] blkdev_get+0xb/0xd
[ Â 56.525853] Â[<ffffffff8823bbf5>] :pktcdvd:pkt_open+0xb5/0xd52
[ Â 56.525876] Â[<ffffffff8108f854>] __d_lookup+0x116/0x142
[ Â 56.525897] Â[<ffffffff8104a8d8>] debug_check_no_locks_freed+0x12b/0x13a
[ Â 56.525922] Â[<ffffffff8104a789>] trace_hardirqs_on+0x11a/0x13e
[ Â 56.525944] Â[<ffffffff81049eef>] lockdep_init_map+0xa6/0x326
[ Â 56.525968] Â[<ffffffff8120d41b>] __mutex_lock_slowpath+0x281/0x2b4
[ Â 56.525990] Â[<ffffffff8104a5b7>] mark_held_locks+0x53/0x71
[ Â 56.526010] Â[<ffffffff8120d41b>] __mutex_lock_slowpath+0x281/0x2b4
[ Â 56.526034] Â[<ffffffff8120ce13>] __mutex_unlock_slowpath+0x129/0x14f
[ Â 56.526054] Â[<ffffffff8120d70c>] mutex_lock_nested+0x298/0x2cd
[ Â 56.526075] Â[<ffffffff8104a5b7>] mark_held_locks+0x53/0x71
[ Â 56.526095] Â[<ffffffff8120d70c>] mutex_lock_nested+0x298/0x2cd
[ Â 56.526117] Â[<ffffffff8104830f>] debug_mutex_free_waiter+0x58/0x5c
[ Â 56.526141] Â[<ffffffff8120d732>] mutex_lock_nested+0x2be/0x2cd
[ Â 56.526165] Â[<ffffffff810a289c>] do_open+0xae/0x2c4
[ Â 56.526184] Â[<ffffffff8120eec6>] _spin_unlock+0x2d/0x4b
[ Â 56.526205] Â[<ffffffff810a2ab2>] blkdev_open+0x0/0x6b
[ Â 56.526225] Â[<ffffffff810a2ae6>] blkdev_open+0x34/0x6b
[ Â 56.526247] Â[<ffffffff8107d664>] __dentry_open+0x128/0x201
[ Â 56.526270] Â[<ffffffff8107d7ce>] nameidata_to_filp+0x2a/0x3c
[ Â 56.526291] Â[<ffffffff8107d81d>] do_filp_open+0x3d/0x4f
[ Â 56.526315] Â[<ffffffff8120eec6>] _spin_unlock+0x2d/0x4b
[ Â 56.526335] Â[<ffffffff8107d1cf>] get_unused_fd+0xfa/0x10b
[ Â 56.526356] Â[<ffffffff8107d87c>] do_sys_open+0x4d/0xd5
[ Â 56.526377] Â[<ffffffff8107d92d>] sys_open+0x1b/0x1d
[ Â 56.526396] Â[<ffffffff81009f6e>] system_call+0x7e/0x83
[ Â 56.526417]
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/