Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.

[Wang C. <wan...@cn...>]

kr...@bi... said the following on 2009-2-19 0:02:
> From: Kristian Høgsberg <kr...@re...>
> 
> A number of GEM operations (and legacy drm ones) want to copy data to
> or from userspace while holding the struct_mutex lock.  However, the
> fault handler calls us with the mmap_sem held and thus enforces the
> opposite locking order.  This patch downs the mmap_sem up front for
> those operations that access userspace data under the struct_mutex
> lock to ensure the locking order is consistent.
> 
> Signed-off-by: Kristian Høgsberg <kr...@re...>

Now I get the following dmesg
=============================================
[ INFO: possible recursive locking detected ]
2.6.29-rc5-default #163
---------------------------------------------
X/3923 is trying to acquire lock:
 (&mm->mmap_sem){----}, at: [<c0168e13>] might_fault+0x42/0x7e

but task is already holding lock:
 (&mm->mmap_sem){----}, at: [<eec2ef5b>] i915_cmdbuffer+0xfa/0x461 [i915]

other info that might help us debug this:
2 locks held by X/3923:
 #0:  (&mm->mmap_sem){----}, at: [<eec2ef5b>] i915_cmdbuffer+0xfa/0x461 [i915]
 #1:  (&dev->struct_mutex){--..}, at: [<eec2ef68>] i915_cmdbuffer+0x107/0x461 [i                                                                             915]

stack backtrace:
Pid: 3923, comm: X Not tainted 2.6.29-rc5-default #163
Call Trace:
 [<c01374ef>] validate_chain+0x4bf/0xbb5
 [<c0138254>] __lock_acquire+0x66f/0x6f9
 [<c0138339>] lock_acquire+0x5b/0x77
 [<c0168e13>] ? might_fault+0x42/0x7e
 [<c0168e30>] might_fault+0x5f/0x7e
 [<c0168e13>] ? might_fault+0x42/0x7e
 [<eec2ec72>] i915_emit_box+0x1d/0x20c [i915]
 [<eec2efd9>] i915_cmdbuffer+0x178/0x461 [i915]
 [<c01ee3f4>] ? copy_from_user+0x31/0x54
 [<eebd085b>] drm_ioctl+0x1a6/0x21b [drm]
 [<eec2ee61>] ? i915_cmdbuffer+0x0/0x461 [i915]
 [<eebd06b5>] ? drm_ioctl+0x0/0x21b [drm]
 [<c0182a85>] vfs_ioctl+0x3d/0x50
 [<c0182f85>] do_vfs_ioctl+0x41b/0x483
 [<c02e8544>] ? do_page_fault+0x2f7/0x5a0
 [<c018302d>] sys_ioctl+0x40/0x5a
 [<c0102cdd>] sysenter_do_call+0x12/0x31