[RTEMS Project] #4528: rate monotonic: reset of CPU usage time not always detected

[RTEMS trac]

#4528: rate monotonic: reset of CPU usage time not always detected
-----------------------------+-----------------------------
  Reporter:  Frank Kuehndel  |      Owner:  Sebastian Huber
      Type:  defect          |     Status:  assigned
  Priority:  normal          |  Milestone:  Indefinite
 Component:  rtems           |    Version:  6
  Severity:  trivial         |   Keywords:
Blocked By:                  |   Blocking:
-----------------------------+-----------------------------
 `rtems_rate_monotonic_get_statistics()` and
 `rtems_rate_monotonic_get_status()` must detect whether the used CPU time
 was resetted during a period (`rtems_cpu_usage_reset()`). This is achieved
 by storing the CPU usage time counter value when the period is started. To
 detect whether there was a reset, the CPU usage time value from the period
 start and the current value are compared. If the current value is lower
 than the one from the start there was a reset.

 The bug is that when the current CPU usage time value is greater than the
 value at the start, a reset may still have occurred.

 For example, when the period starts the used CPU time is at 1000 and 1000
 is stored. Then the CPU time counter is resetted - so it is 0. Assume the
 period thread does some work and the CPU usage time is at 100 when
 `rtems_rate_monotonic_get_status()` is called. In this case the current
 code detects the reset and returns correctly `RTEMS_NOT_DEFINED`. Yet,
 when more CPU usage time passes without `rtems_rate_monotonic_period()`
 being called - lets say the used CPU time is at 1200 - and
 `rtems_rate_monotonic_get_status()` is called, the stored value (1000) is
 smaller than the current one (1200) so the reset is not detected.

 This bug has been found with a test which manipulates the time directly. I
 doubt this bug is very relevant in practice. It requires that there are
 periods with long intervals and much CPU load and that either the system
 is shortly started or `rtems_cpu_usage_reset()` is used frequently.

 The background:

 The Classic API guide https://docs.rtems.org/branches/master/c-user/rate-
 monotonic/directives.html#rtems-rate-monotonic-get-status says for
 `rtems_rate_monotonic_get_status()`:

 `RTEMS_NOT_DEFINED`: There was no status available due to a reset of the
 processor time usage of the owner task of the period.

 The directive `rtems_cpu_usage_reset()` sets `the_thread->cpu_time_used` 0
 in line 43 of `cpukit/libmisc/cpuuse/cpuusagereset.c`.

 The detection whether there was an reset or not is done in file
 `cpukit/rtems/src/ratemonperiod.c` line 56 in function
 `_Rate_monotonic_Get_status()`:

 {{{
   [...]
   /*
    *  Determine cpu usage since period initiated.
    */
   _Thread_Get_CPU_time_used( owning_thread, &used );

   /*
    *  The cpu usage info was reset while executing.  Can't
    *  determine a status.
    */
   if ( _Timestamp_Less_than( &used,
 &the_period->cpu_usage_period_initiated ) )
     return false;
   [...]
 }}}

 The directive `rtems_rate_monotonic_get_statistics()` is affected
 indirectly because collecting its data is skipped when there was a reset.
 `cpukit/rtems/src/ratemonperiod.c` line 149 in function
 `_Rate_monotonic_Update_statistics()` (which in turn calls the above
 code).

 For the records:

 {{{
 RTEMS_VERSION    = 6.0.0
 remote origin    = git://git.rtems.org/sebh/rtems.git
 commit HEAD      = 1df2666ca1d73807a338e0d209ed1f42f67f00a9  (HEAD,
 origin/qual-43)
 config.ini       =
     [arm/realview_pbx_a9_qemu]
     RTEMS_DEBUG = True
     RTEMS_NETWORKING = True
     RTEMS_POSIX_API = True
     RTEMS_SMP = True
     BUILD_SAMPLES = False
     BUILD_VALIDATIONTESTS = True
     BUILD_UNITTESTS = True
 NEWLIB_VERSION   = 3.2.0
 SOURCE_BUILDER   = Set Builder, 6 (f12dee02d52d)
 GCC_VERSION      = arm-rtems6-gcc (GCC) 10.3.1 20210409 (RTEMS 6, RSB
 c938bd7cbe16bd03d3b382f2d7cfee6a86aa9424, Newlib 0c0f3df)
 BINUTILS_VERSION = GNU ld (GNU Binutils) 2.36.1.20210409
 }}}

--
Ticket URL: <http://devel.rtems.org/ticket/4528>
RTEMS Project <http://www.rtems.org/>
RTEMS Project