[ofa-general] [Fwd: [PATCH] ib: release locks in the proper order]

[Steven Rostedt]

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