Description of problem: ============================================= [ INFO: possible recursive locking detected ] 2.6.18-201.el5debug #1 --------------------------------------------- dmraid/590 is trying to acquire lock: (&bdev->bd_mutex){--..}, at: [<ffffffff80155021>] blkdev_ioctl+0x55b/0x69d but task is already holding lock: (&bdev->bd_mutex){--..}, at: [<ffffffff80154fe3>] blkdev_ioctl+0x51d/0x69d other info that might help us debug this: 1 lock held by dmraid/590: #0: (&bdev->bd_mutex){--..}, at: [<ffffffff80154fe3>] blkdev_ioctl+0x51d/0x69d stack backtrace: Call Trace: [<ffffffff800aa528>] __lock_acquire+0xa1/0xade [<ffffffff80155021>] blkdev_ioctl+0x55b/0x69d [<ffffffff800aafba>] lock_acquire+0x55/0x6f [<ffffffff80155021>] blkdev_ioctl+0x55b/0x69d [<ffffffff80067224>] mutex_lock_nested+0x104/0x29c [<ffffffff800f0ce6>] get_super+0x95/0x9d [<ffffffff80155021>] blkdev_ioctl+0x55b/0x69d [<ffffffff800f1f68>] blkdev_open+0x23/0x4f [<ffffffff8001fb67>] __dentry_open+0x104/0x1e2 [<ffffffff800f128e>] block_ioctl+0x1b/0x1f [<ffffffff80044863>] do_ioctl+0x21/0x6b [<ffffffff80031e02>] vfs_ioctl+0x45d/0x4bf [<ffffffff8004f004>] sys_ioctl+0x59/0x78 [<ffffffff80060116>] system_call+0x7e/0x83 Version-Release number of selected component (if applicable): 2.6.18-201.el5debug How reproducible: not sure Steps to Reproduce: 1. I saw this after booting my test box, metallica. 2. 3.
This one looks a bit outdated? Can we close it? Cheers, Jes
I tried the -201.el5debug kernel again on the same host, and I got a different circular locking warning. So, I can't reliably reproduce this on -201. I also booted the 327.el5debug kernel, and there I witnessed no circular locking dependencies. So, yes, I think we can ignore this one until and unless it rears its ugly head again.