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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/