[LITMUS^RT] possible inheritance/boosting conflict

[Glenn Elliott]

Hi All,

I was reviewing the code in edf_higher_prio(), and I think that I may have stumbled across a bug.  I don’t believe that we’ve actually ever hit this bug before because it requires a task to both inherit a priority and itself be boosted.  Nevertheless, I think edf_higher_prio() should be robust enough to handle such a case.

High-level outline of edf_higher_prio():

(1) In the block of code starting at line 71 (https://github.com/LITMUS-RT/litmus-rt/blob/master/litmus/edf_common.c#L71), we override the task pointers with pointers to any inherited tasks.

(2) We next check for boosted priorities starting at line 78.  The task with boosted priority wins (ties are broken by boost-start-time).

(3) Continue to compare priority of tasks…

Suppose the following scenario:
* Task A inherits from Task T
* Task A is boosted, starting at time t0
* Task B is boosted, starting at time t1
* Task T is not boosted.

We want to compare the priorities of tasks A and B.  Because of (1), we compare the priorities of Task T (on behalf of Task A) to Task B.  Task B has higher priority than Task T.  This is a bug because the boosted priority of Task A should supersede the lower priority of Task T.

- Proposed Fix -
In (1), for Task A with inherited priority from Task T, use priority of Task T iff:
(a) Task A is not boosted 
OR
(b) Task A is boosted and Task T is boosted and Task T has an earlier boost-start-time of Task A.

Is this a bug?  I think one can argue that Task A should not have inherited from Task T if Task A was already boosted when inheritance was established, or the inheritance should have been terminated when Task A was boosted after inheritance was established.

-Glenn