[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53415E82.9030007@oracle.com>
Date: Sun, 06 Apr 2014 10:02:42 -0400
From: Sasha Levin <sasha.levin@...cle.com>
To: mchehab@...hat.com
CC: linux-media@...r.kernel.org, Dave Jones <davej@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: v4l2: lockdep spew mmap_sem/dev_mutex
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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists