Interesting, I'm pretty sure that I haven't touched the locking order of
the cs_mutex vs. vm_mutex.
Maybe it is just some kind of side effect, going to locking into it anyway.
Christian.
On 21.04.2012 13:39, Dave Airlie wrote:
running 3.4.0-rc3 + Christian's reset patch series.
The locks are definitely taken in different orders between vm_bo_add
and cs ioctl.
Dave.
======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc3+ #33 Not tainted
-------------------------------------------------------
shader_runner/3090 is trying to acquire lock:
(&vm->mutex){+.+...}, at: [<ffffffffa00c513f>]
radeon_cs_ioctl+0x438/0x5c1 [radeon]
but task is already holding lock:
(&rdev->cs_mutex){+.+.+.}, at: [<ffffffffa00c4d3a>]
radeon_cs_ioctl+0x33/0x5c1 [radeon]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&rdev->cs_mutex){+.+.+.}:
[<ffffffff810757f5>] lock_acquire+0xf0/0x116
[<ffffffff81427881>] mutex_lock_nested+0x6a/0x2bb
[<ffffffffa00b5f4d>] radeon_vm_bo_add+0x118/0x1f5 [radeon]
[<ffffffffa00b6479>] radeon_vm_init+0x6b/0x70 [radeon]
[<ffffffffa00a3bfc>] radeon_driver_open_kms+0x68/0x9a [radeon]
[<ffffffffa0019698>] drm_open+0x201/0x587 [drm]
[<ffffffffa0019b0a>] drm_stub_open+0xec/0x14a [drm]
[<ffffffff8110f788>] chrdev_open+0x11c/0x145
[<ffffffff8110a23a>] __dentry_open+0x17e/0x29b
[<ffffffff8110b138>] nameidata_to_filp+0x5b/0x62
[<ffffffff811188d0>] do_last+0x75d/0x771
[<ffffffff81118ab3>] path_openat+0xcb/0x380
[<ffffffff81118e51>] do_filp_open+0x33/0x81
[<ffffffff8110b23f>] do_sys_open+0x100/0x192
[<ffffffff8110b2ed>] sys_open+0x1c/0x1e
[<ffffffff81430722>] system_call_fastpath+0x16/0x1b
-> #0 (&vm->mutex){+.+...}:
[<ffffffff81074c99>] __lock_acquire+0xfcd/0x1664
[<ffffffff810757f5>] lock_acquire+0xf0/0x116
[<ffffffff81427881>] mutex_lock_nested+0x6a/0x2bb
[<ffffffffa00c513f>] radeon_cs_ioctl+0x438/0x5c1 [radeon]
[<ffffffffa00187a9>] drm_ioctl+0x2d8/0x3a4 [drm]
[<ffffffff8111afd6>] do_vfs_ioctl+0x469/0x4aa
[<ffffffff8111b068>] sys_ioctl+0x51/0x75
[<ffffffff81430722>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&rdev->cs_mutex);
lock(&vm->mutex);
lock(&rdev->cs_mutex);
lock(&vm->mutex);
*** DEADLOCK ***
1 lock held by shader_runner/3090:
#0: (&rdev->cs_mutex){+.+.+.}, at: [<ffffffffa00c4d3a>]
radeon_cs_ioctl+0x33/0x5c1 [radeon]
stack backtrace:
Pid: 3090, comm: shader_runner Not tainted 3.4.0-rc3+ #33
Call Trace:
[<ffffffff81420ac7>] print_circular_bug+0x28a/0x29b
[<ffffffff81074c99>] __lock_acquire+0xfcd/0x1664
[<ffffffff810757f5>] lock_acquire+0xf0/0x116
[<ffffffffa00c513f>] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
[<ffffffff810db991>] ? might_fault+0x57/0xa7
[<ffffffff81427881>] mutex_lock_nested+0x6a/0x2bb
[<ffffffffa00c513f>] ? radeon_cs_ioctl+0x438/0x5c1 [radeon]
[<ffffffffa00f4196>] ? evergreen_ib_parse+0x1b2/0x204 [radeon]
[<ffffffffa00c513f>] radeon_cs_ioctl+0x438/0x5c1 [radeon]
[<ffffffffa00187a9>] drm_ioctl+0x2d8/0x3a4 [drm]
[<ffffffffa00c4d07>] ? radeon_cs_finish_pages+0xa3/0xa3 [radeon]
[<ffffffff811ee4c4>] ? avc_has_perm_flags+0xd7/0x160
[<ffffffff811ee413>] ? avc_has_perm_flags+0x26/0x160
[<ffffffff8104bf6a>] ? up_read+0x1b/0x32
[<ffffffff8111afd6>] do_vfs_ioctl+0x469/0x4aa
[<ffffffff8111b068>] sys_ioctl+0x51/0x75
[<ffffffff8104f955>] ? __wake_up+0x1d/0x48
[<ffffffff81430722>] system_call_fastpath+0x16/0x1b
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
