priority ceiling inheritance in wrong location

[Joel Sherrill]

The code in question was discussed in the following thread but was
determined that it was not a critical issue. This decision was because
threads were not reordered on priority thread queues on priority changes.
Whether a thread's priority was elevated when it blocked or when it
received the mutex doesn't matter since it blocked using its original
priority.

​http://www.rtems.com/ml/rtems-users/2006/may/msg00052.html

However, with the idea of reordering of priority queues on
thread priority under consideration, this is a serious issue.
Consider this:

+ T1 (priority=low) blocks on priority ceiling mutex
+ T1 inherits ceiling priority (priority=high) and the

thread queue is reordered to reflect this.

Now every thread that blocks will have its priority changed to
the ceiling and the blocking list will effectively be FIFO.

Worse, the priority change is made inside a check to see if the
mutex was successfully acquired. This assumes the thread actually
blocked between the call to _Thread_queue_Enqueue and the check.
Since this is in a dispatching disabled critical section, the thread
continues to run and its priority is ALWAYS changed to the ceiling.
It is conceivable (although not demonstrated) that the thread could
timeout waiting and already have inherited the priority.

Release:
4.5 4.6 4.7 CVS

Environment:
All

[Joel Sherrill]

State-Changed-From-To: open->closed
State-Changed-Why: Patched on 4.6 and CVS head.

There are patches attached for 4.5, 4.6, and 4.7.

[Joel Sherrill]

pri1124-47.diff