Krzysztof Helt wrote: > On Sat, 11 Apr 2009 00:05:22 +0200 > Andrea Righi <righi.andrea@xxxxxxxxx> wrote: > >> mmmh... I may have missed something, but the common fb_mmap() should >> acquire mm->mmap_sem and then info->lock, while fb_ioctl() can do that >> in reverse order (info->lock first and then mm->mmap_sem) causing the >> circular locking dependency. Are you sure that pushing info->lock down >> each driver's fb_mmap will fix the problem? > > Right. The fb_mmap is called with the mmap_sem already held. > I will try other possibilities like breaking info->lock() into two > mutexex. I had to deal with interaction of mmap_sem with a driver lock twice yet. I solved it cheaply by replacing mutex_lock(driver_mutex) by mutex_trylock(driver_mutex). The obvious drawback is that thic changes kernel behaviour visibly to userspace: Under contention, the ioctl/read/write fails with -EAGAIN instead of being blocked until the other thread finished its ioctl/read/write/mmap on the same fd (if the driver mutex is instantiated per fd, like in my case). http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8449fc3ae58bf8ee5acbd2280754cde67b5db128 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=638570b54346f140bc09b986d93e76025d35180f (In these two drivers, the change of behaviour is irrelevant to real userspace clients.) -- Stefan Richter -=====-=-=== -=-= -==-= http://arcgraph.de/sr/ _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
