2012/4/21 Christian König <deathsimple@xxxxxxxxxxx>: > On 21.04.2012 16:08, Jerome Glisse wrote: >> >> 2012/4/21 Christian König<deathsimple@xxxxxxxxxxx>: >>> >>> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
