VM lockdep warning

From: Dave Airlie <airlied@gmail.com>
To: dri-devel <dri-devel@lists.freedesktop.org>,
	"Christian König" <deathsimple@vodafone.de>
Subject: VM lockdep warning
Date: Sat, 21 Apr 2012 12:39:32 +0100	[thread overview]
Message-ID: <CAPM=9tyDqqtrQAUByMLNhYY3OLQWg1fJ2acMOAVk1hhsncLayw@mail.gmail.com> (raw)

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