[RTEMS Project] #3829: 4.10: PIP Corruption

[RTEMS trac]

#3829: 4.10: PIP Corruption
--------------------------+---------------------------
 Reporter:  Gedare Bloom  |       Owner:  Gedare Bloom
     Type:  defect        |      Status:  assigned
 Priority:  normal        |   Milestone:  4.10.3
Component:  admin         |     Version:  4.10
 Severity:  blocker       |  Resolution:
 Keywords:                |  Blocked By:
 Blocking:                |
--------------------------+---------------------------
Description changed by Gedare Bloom:

Old description:

> The 4.10 priority inheritance protocol was modified in #3359. This
> modification was only applied to 4.10, because 4.11 and 5.0 have been
> changed in other ways to deal with PIP problems in the
> scheduler/synchronization logic.
>
> A user reports that they encounter memory corruption (unaligned memory or
> data access exception) while using the modified PIP. The specifics have
> seemingly been narrowed down to the situation of using a (binary)
> semaphore with a timeout
>
> ```
>     status = rtems_semaphore_create( r_name,
>                                      1,
>
>                                      (RTEMS_SIMPLE_BINARY_SEMAPHORE |
> RTEMS_PRIORITY),
>
>                                      0,
>
>                                      &id);
> ```
>
> The simple binary semaphore create in the code snippet does not use
> priority inheritance protocol (rightly, since using PIP with simple
> binary semaphore is an error). It would seem that there could be a bug
> introduced in semaphore interactions for non-PIP semaphores in the
> modified PIP handling. The bookkeeping for PIP handling should be checked
> against the code paths for simple binary semaphores.
>
> Relatedly, there does not seem to be any test in rtems-4.10 for
> rtems_semaphore_obtain() on a simple binary semaphore with a timeout.

New description:

 The 4.10 priority inheritance protocol was modified in #3359. This
 modification was only applied to 4.10, because 4.11 and 5.0 have been
 changed in other ways to deal with PIP problems in the
 scheduler/synchronization logic.

 A user reports that they encounter memory corruption (unaligned memory or
 data access exception) while using the modified PIP. The specifics have
 seemingly been narrowed down to the situation of using a (binary)
 semaphore with a timeout

 {{{
     status = rtems_semaphore_create( r_name,
                                      1,

                                      (RTEMS_SIMPLE_BINARY_SEMAPHORE |
 RTEMS_PRIORITY),

                                      0,

                                      &id);
 }}}

 The simple binary semaphore create in the code snippet does not use
 priority inheritance protocol (rightly, since using PIP with simple binary
 semaphore is an error). It would seem that there could be a bug introduced
 in semaphore interactions for non-PIP semaphores in the modified PIP
 handling. The bookkeeping for PIP handling should be checked against the
 code paths for simple binary semaphores.

 Relatedly, there does not seem to be any test in rtems-4.10 for
 rtems_semaphore_obtain() on a simple binary semaphore with a timeout.

--

--
Ticket URL: <http://devel.rtems.org/ticket/3829#comment:1>
RTEMS Project <http://www.rtems.org/>
RTEMS Project