Eric Anholt wrote:
On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
Dave, dri guys,
Could you take a look at this circular dependency please (below)? I
observe it when suspending laptop with radeon drm loaded and with
lockdep enabled. It seems that the root of the problem is that
various vm ops such as drm_vm_open, drm_mmap) are called with mm
semaphore taken, and take dev->struct_mutex. On the other hand,
drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
which depends on mm semaphore indirectly.
What do you think?
Yes, there are real lock inversions now due to the GTT mmap code. It's
going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
path to go away, but the fact that mmap_sem is held over the fault
handler pretty much kills that). It's high on the list, though.
Shouldn't it be possible to relax this given that in the fault()
handler, the mmap_sem() is taken in read mode only. This means that it
should be deadlock-safe (but still a little ugly) to take the mmap_sem()
in read mode when the struct mutex is held.
Another quick way to fix potential deadlocks, would be to take the
struct mutex in the following way in fault():
if (!mutex_trylock(&dev->struct_mutex)) {
needs_resched();
return VM_FAULT_NOPAGE;
}
/Thomas
------------------------------------------------------------------------
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
------------------------------------------------------------------------
--
_______________________________________________
Dri-devel mailing list
Dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
