Re: [REGRESSION] commit 66c1ca0: {fbmem: fix fb_info->lock and mm->mmap_sem ...} causes Xfbdev not working

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Krzysztof Helt wrote:
> On Sat, 11 Apr 2009 00:05:22 +0200
> Andrea Righi <righi.andrea@gmail.com> 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/