Kristian Høgsberg wrote: > > > In this case, I guess the fault handler is always only called with > mmap_sem held in read mode, and then yes, there's no deadlock and the > warning is harmless. That doesn't mean that it's a good idea - > enforcing a consistent lock order is good practice that keeps the code > clean and makes it easy to verify locking without knowing every part > of the system in detail. And should the fault callback mmap_sem > assumptions change in the future, gem will certainly be more robust if > we keep the locking simple. > Yes, but in this case you'll have
read_lock(mmap_sem) mutex_lock(struct_mutex) read_lock(mmap_sem) Which both reverses locking order between the last two locks and does recursive locking. This won't cause deadlocks but will still warn. So one bad thing is traded against another. /Thomas > cheers, > Kristian > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
