VM lockdep warning
j.glisse at gmail.com
Sat Apr 21 07:50:11 PDT 2012
2012/4/21 Christian König <deathsimple at vodafone.de>:
> On 21.04.2012 16:08, Jerome Glisse wrote:
>> 2012/4/21 Christian König<deathsimple at vodafone.de>:
>>> Interesting, I'm pretty sure that I haven't touched the locking order of
>>> cs_mutex vs. vm_mutex.
>>> Maybe it is just some kind of side effect, going to locking into it
>> It's the using, init path take lock in different order than cs path
> Well, could you explain to me why the vm code takes cs mutex in the first
> It clearly has it's own mutex and it doesn't looks like that it deals with
> any cs related data anyway.
Lock simplification is on my todo. The issue is that vm manager is protected by
cs_mutex The vm.mutex is specific to each vm it doesn't protect the global vm
management. I didn't wanted to introduce a new global vm mutex as vm activity
is mostly trigger on behalf of cs so i dediced to use the cs mutex.
That's why non cs path of vm need to take the cs mutex.
More information about the dri-devel