Re: Deadlock on the mm->mmap_sem

[David Howells <dhowells@redhat.com>]

> > i386 has a fair rwsemaphore, too - probably other archs must be modified
> > as well.
> 
> yes, actually my patch was against the rwsem patch in -aa, and in -aa
> I'm using the generic semaphores for all archs in the tree so it fixes
> the race for all them. The mainline semaphores are slightly different.

Wasn't there a problem with unfair rw-semaphores? I can't remember exactly
now...

> > IMHO modifying proc_pid_read_maps() is far simpler - I'm not aware of
> > another recursive mmap_sem user.
> 
> if that's the very only place that could be a viable option but OTOH I
> like to be allowed to use recursion on the read locks as with the
> spinlocks. I think another option would be to have reacursion allowed on
> the default read locks and then make a down_read_fair that will block at
> if there's a down_write under us. we can very cleanly implement this,
> the same can be done cleanly also for the spinlocks: read_lock_fair. One
> can even mix the read_lock/read_lock_fair or the
> down_read/down_read_fair together. For example assuming we use the
> recursive semaphore fix in proc_pid_read_maps the down_read over there
> could be converted to a down_read_fair (but that's just an exercise, if
> the page fault isn't fair it doesn't worth to have proc_pid_read_maps
> fair either).

If this were to be done, I'd prefer to keep down_read() as being fair and add
a down_read_unfair(). This'd have the least impact on the current behaviour,
and I suspect we actually want fairness most of the time.

Of course, I'd personally prefer to avoid recursive semaphore situations where
possible too... it sounds far too much like trouble waiting to happen, but we
can't have everything.

David