summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_ringbuffer.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2010-11-08 01:12:29 +0000
committerChris Wilson <chris@chris-wilson.co.uk>2010-11-08 09:19:11 +0000
commitb47b30ccdaad5f2fc39a1a65921bffd150574a91 (patch)
tree9eaef1721b05daa71010de638e02b2e6b4850598 /drivers/gpu/drm/i915/intel_ringbuffer.c
parent16a02cf08a2de0863daf7ebb91718d7c6bbe7f9c (diff)
downloadtalos-obmc-linux-b47b30ccdaad5f2fc39a1a65921bffd150574a91.tar.gz
talos-obmc-linux-b47b30ccdaad5f2fc39a1a65921bffd150574a91.zip
drm/i915: Avoid might_fault during pwrite whilst holding our mutex
... and so prevent a potential circular reference: [ INFO: possible circular locking dependency detected ] 2.6.37-rc1-uwe1+ #4 ------------------------------------------------------- Xorg/1401 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [<c01e4ddb>] might_fault+0x4b/0xa0 but task is already holding lock: (&dev->struct_mutex){+.+.+.}, at: [<f869c3ac>] i915_mutex_lock_interruptible+0x3c/0x60 [i915] which lock already depends on the new lock. When the locking around the pwrite ioctl was simplified, I did not spot that the phys path never took any locks and so we introduced this potential circular reference. Reported-by: Uwe Helm <uwe.helm@googlemail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Diffstat (limited to 'drivers/gpu/drm/i915/intel_ringbuffer.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud