linux-kernel - Re: [Bug #12574] possible circular locking dependency detected

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49927A02.9020006@shipmail.org>
Date:	Wed, 11 Feb 2009 08:10:58 +0100
From:	Thomas Hellström <thomas@...pmail.org>
To:	Eric Anholt <eric@...olt.net>
CC:	"Michael S. Tsirkin" <m.s.tsirkin@...il.com>,
	Dave Airlie <airlied@...ux.ie>,
	"Rafael J. Wysocki" <rjw@...k.pl>, dri-devel@...ts.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [Bug #12574] possible circular locking dependency detected

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@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>   



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/