Rafael J. Wysocki said the following on 2009-2-15 4:38:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419
> Subject : possible circular locking dependency on i915 dma
> Submitter : Wang Chen <[email protected]>
> Date : 2009-01-08 14:11 (38 days old)
> References : http://marc.info/?l=linux-kernel&m=123142399720125&w=4
>
>
Yes. It's still there in mainline.
I think the commit 546b0974c39657017407c86fe79811100b60700d
"i915: Use struct_mutex to protect ring in GEM mode." brought this regression.
The lockdep problem is as following:
thread-1
i915_cmdbuffer()
|
---> lock(drm_device->struct_mutex)
|
V
i915_dispatch_cmdbuffer()
|
---->i915_emit_box()
|
----->copy_from_user()
|
-----might_fault()
|
--->lock(mm->mmap_sem)
thread-2
dup_mm()
|
--->lock(mm->mmap_sem)
|
V
drm_vm_open()
|
-------> lock(drm_device->struct_mutex)
The different order to lock "mmap_sem" and "drm_dev->struct_mutex" introduces
the problem.
But it seems no way to reverse the lock order in i915.
So how about refine the lock granularity of drm_dev->struct_mutex and exclude
the mmap_sem
lock/unlock out of the drm_dev->struct_mutex lock/unlock range?
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
