• Chris Wilson's avatar
    drm/i915: Do not hold mutex when faulting in user addresses · 51311d0a
    Chris Wilson authored
    Linus Torvalds found that it was rather trivial to trigger a system
    freeze:
    
      In fact, with lockdep, I don't even need to do the sysrq-d thing: it
      shows the bug as it happens. It's the X server taking the same lock
      recursively.
    
      Here's the problem:
    
        =============================================
        [ INFO: possible recursive locking detected ]
        2.6.37-rc2-00012-gbdbd01ac #7
        ---------------------------------------------
        Xorg/2816 is trying to acquire lock:
         (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c626c>] i915_gem_fault+0x50/0x17e
    
        but task is already holding lock:
         (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
    
        other info that might help us debug this:
        2 locks held by Xorg/2816:
         #0:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
         #1:  (&mm->mmap_sem){++++++}, at: [<ffffffff81022d4f>] page_fault+0x156/0x37b
    
    This recursion was introduced by rearranging the locking to avoid the
    double locking on the fast path (4f27b5d and fbd5a26d) and the
    introduction of the prefault to encourage the fast paths (b5e4f2b). In
    order to undo the problem, we rearrange the code to perform the access
    validation upfront, attempt to prefault and then fight for control of the
    mutex.  the best case scenario where the mutex is uncontended the
    prefaulting is not wasted.
    Reported-and-tested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    51311d0a
i915_gem.c 131 KB