VM lockdep warning
Jerome Glisse
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
>>> the
>>> cs_mutex vs. vm_mutex.
>>>
>>> Maybe it is just some kind of side effect, going to locking into it
>>> anyway.
>>>
>>> Christian.
>>>
>> 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
> place?
>
> It clearly has it's own mutex and it doesn't looks like that it deals with
> any cs related data anyway.
>
> Christian.
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.
Cheers,
Jerome
More information about the dri-devel
mailing list