Re: v4l2: lockdep spew mmap_sem/dev_mutex

[Sasha Levin <sasha.levin@oracle.com>]

Ping? This is still happening in -next, more than half a year later...


Thanks,
Sasha

On 05/06/2013 09:29 PM, Sasha Levin wrote:
> Hi guys,
> 
> While fuzzing with trinity running inside a KVM tools guest, using latest -next kernel,
> I've stumbled on the following spew:
> 
> [  160.267181] ======================================================
> [  160.267896] [ INFO: possible circular locking dependency detected ]
> [  160.268631] 3.9.0-next-20130506-sasha-00012-g01de88a #356 Tainted: G        W
> [  160.269486] -------------------------------------------------------
> [  160.271108] trinity-child3/10132 is trying to acquire lock:
> [  160.271108]  (&dev->dev_mutex){+.+.+.}, at: [<ffffffff831c39f1>] m2mtest_mmap+0x51/0x90
> [  160.271108]
> [  160.271108] but task is already holding lock:
> [  160.271108]  (&mm->mmap_sem){++++++}, at: [<ffffffff8124ff02>] vm_mmap_pgoff+0x62/0xd0
> [  160.271108]
> [  160.271108] which lock already depends on the new lock.
> [  160.271108]
> [  160.271108]
> [  160.271108] the existing dependency chain (in reverse order) is:
> [  160.271108]
> -> #1 (&mm->mmap_sem){++++++}:
> [  160.271108]        [<ffffffff811a1f5a>] lock_acquire+0x1aa/0x240
> [  160.271108]        [<ffffffff81259f8b>] might_fault+0x7b/0xa0
> [  160.271108]        [<ffffffff8315d82e>] video_usercopy+0x41e/0x490
> [  160.271108]        [<ffffffff8315d8b0>] video_ioctl2+0x10/0x20
> [  160.271108]        [<ffffffff83157c33>] v4l2_ioctl+0xa3/0x170
> [  160.271108]        [<ffffffff812bff52>] do_vfs_ioctl+0x522/0x570
> [  160.271108]        [<ffffffff812bfffd>] SyS_ioctl+0x5d/0xa0
> [  160.271108]        [<ffffffff84028558>] tracesys+0xe1/0xe6
> [  160.271108]
> -> #0 (&dev->dev_mutex){+.+.+.}:
> [  160.271108]        [<ffffffff811a0e4f>] __lock_acquire+0x15af/0x1e40
> [  160.271108]        [<ffffffff811a1f5a>] lock_acquire+0x1aa/0x240
> [  160.271108]        [<ffffffff8401bf89>] __mutex_lock_common+0x59/0x600
> [  160.271108]        [<ffffffff8401c56f>] mutex_lock_interruptible_nested+0x3f/0x50
> [  160.271108]        [<ffffffff831c39f1>] m2mtest_mmap+0x51/0x90
> [  160.271108]        [<ffffffff831576b8>] v4l2_mmap+0x48/0xa0
> [  160.271108]        [<ffffffff81265fbb>] mmap_region+0x33b/0x630
> [  160.271108]        [<ffffffff812665c6>] do_mmap_pgoff+0x316/0x3d0
> [  160.271108]        [<ffffffff8124ff23>] vm_mmap_pgoff+0x83/0xd0
> [  160.271108]        [<ffffffff81264b2e>] SyS_mmap_pgoff+0x16e/0x1b0
> [  160.271108]        [<ffffffff8106ea2d>] SyS_mmap+0x1d/0x20
> [  160.271108]        [<ffffffff84028558>] tracesys+0xe1/0xe6
> [  160.271108]
> [  160.271108] other info that might help us debug this:
> [  160.271108]
> [  160.271108]  Possible unsafe locking scenario:
> [  160.271108]
> [  160.271108]        CPU0                    CPU1
> [  160.271108]        ----                    ----
> [  160.271108]   lock(&mm->mmap_sem);
> [  160.271108]                                lock(&dev->dev_mutex);
> [  160.271108]                                lock(&mm->mmap_sem);
> [  160.271108]   lock(&dev->dev_mutex);
> [  160.271108]
> [  160.271108]  *** DEADLOCK ***
> [  160.271108]
> [  160.271108] 1 lock held by trinity-child3/10132:
> [  160.271108]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8124ff02>] vm_mmap_pgoff+0x62/0xd0
> [  160.271108]
> [  160.271108] stack backtrace:
> [  160.271108] CPU: 3 PID: 10132 Comm: trinity-child3 Tainted: G        W    3.9.0-next-20130506-sasha-00012-g01de88a #356
> [  160.271108]  ffffffff86ba8bf0 ffff8800ab3aba78 ffffffff83fde6a3 ffff8800ab3abac8
> [  160.271108]  ffffffff83fd33cf 0000000000abc6d5 ffff8800ab3abb58 ffff8800ab3abac8
> [  160.271108]  ffff88009314b9b0 ffff88009314b978 ffff88009314b000 0000000000abc6d5
> [  160.271108] Call Trace:
> [  160.271108]  [<ffffffff83fde6a3>] dump_stack+0x19/0x1b
> [  160.271108]  [<ffffffff83fd33cf>] print_circular_bug+0x1fb/0x20c
> [  160.271108]  [<ffffffff811a0e4f>] __lock_acquire+0x15af/0x1e40
> [  160.271108]  [<ffffffff8401fb60>] ? _raw_spin_unlock+0x30/0x60
> [  160.271108]  [<ffffffff811a1f5a>] lock_acquire+0x1aa/0x240
> [  160.271108]  [<ffffffff831c39f1>] ? m2mtest_mmap+0x51/0x90
> [  160.271108]  [<ffffffff8401bf89>] __mutex_lock_common+0x59/0x600
> [  160.271108]  [<ffffffff831c39f1>] ? m2mtest_mmap+0x51/0x90
> [  160.271108]  [<ffffffff8119e9aa>] ? __lock_is_held+0x5a/0x80
> [  160.271108]  [<ffffffff81265ee4>] ? mmap_region+0x264/0x630
> [  160.271108]  [<ffffffff831c39f1>] ? m2mtest_mmap+0x51/0x90
> [  160.271108]  [<ffffffff8401c56f>] mutex_lock_interruptible_nested+0x3f/0x50
> [  160.271108]  [<ffffffff831c39f1>] m2mtest_mmap+0x51/0x90
> [  160.271108]  [<ffffffff81265ee4>] ? mmap_region+0x264/0x630
> [  160.271108]  [<ffffffff831576b8>] v4l2_mmap+0x48/0xa0
> [  160.271108]  [<ffffffff81265fbb>] mmap_region+0x33b/0x630
> [  160.271108]  [<ffffffff812665c6>] do_mmap_pgoff+0x316/0x3d0
> [  160.271108]  [<ffffffff8124ff02>] ? vm_mmap_pgoff+0x62/0xd0
> [  160.271108]  [<ffffffff8124ff23>] vm_mmap_pgoff+0x83/0xd0
> [  160.271108]  [<ffffffff81a4a889>] ? __const_udelay+0x29/0x30
> [  160.271108]  [<ffffffff81151824>] ? __rcu_read_unlock+0x44/0xb0
> [  160.271108]  [<ffffffff812cace0>] ? fget_raw+0x280/0x280
> [  160.271108]  [<ffffffff81264b2e>] SyS_mmap_pgoff+0x16e/0x1b0
> [  160.271108]  [<ffffffff8106ea2d>] SyS_mmap+0x1d/0x20
> [  160.271108]  [<ffffffff84028558>] tracesys+0xe1/0xe6
> 
> Thanks,
> Sasha
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>