Roland Dreier wrote:
> Forwarding a patch written by one of our real time kernel guys.
Is there some reason why sending the patch himself is too hard?
> RT is very sensitive to the order locks are taken and released
> wrt read write locks. We must do
>
> lock(a);
> lock(b);
> lock(c);
>
> [...]
>
> unlock(c);
> unlock(b);
> unlock(a);
>
> otherwise bad things can happen.
Maybe I'm being dense but what bad things are fixed by this patch? I
can't even see a theoretical issue with the code as is. This change
looks very much like fiddling for no good reason -- has a real problem
been seen with this code?
No problem upstream (or mainline for that matter). And with my latest
email back and forth with Linus, it may be best to just drop it from
going upstream.
The problem arised with RT. RT converts spin_locks and rwlocks as well
as rwsems into priority inheritance mutexes. With rwlocks and rwsems it
becomes a bit more complex, since they can have multiple owners. To
accomplish this, the tasks have an array field of all reader locks
(rwlocks or sems) that they hold. But the unlock expected the last taken
lock to be released, to keep the array clean (just decrement the length).
I have just finished testing a patch that allows for this array to have
holes in it (and unnested unlocking order), but until it is in, we need
this patch for RT.
-- Steve
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
