RTEMS | score: Fix TOD_LATEST_YEAR and watchdog overflow beyond 2400 (!1484)

[Sebastian Huber (@sebhub)]

Sebastian Huber commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1484#note_158980


The direction is right.  The limit belongs in the input check, and this
branch puts it there.

`_Watchdog_Tick()` converts the current CLOCK_REALTIME on every tick,
`cpukit/score/src/watchdogtick.c:128`:

```c
  header = &cpu->Watchdog.Header[ PER_CPU_WATCHDOG_REALTIME ];
  first = _Watchdog_Header_first( header );

  if ( first != NULL ) {
    _Timecounter_Getnanotime( &now );
    _Watchdog_Tickle(
      header,
      first,
      _Watchdog_Ticks_from_timespec( &now ),
```

`_Watchdog_Ticks_from_timespec()` asserts
`!_Watchdog_Is_far_future_timespec( ts )` at
`cpukit/include/rtems/score/watchdogimpl.h:552`.  A time of day above
`WATCHDOG_MAX_SECONDS` therefore breaks every tick which follows the set.
A debug build asserts.  A release build tickles the realtime collection
with a wrapped value for the rest of the run.  So `rtems_clock_set()` must
reject the year, and a relaxed `_TOD_Set()` cannot repair it.

## `psxclock` fails with this branch

`testsuites/psxtests/psxclock/init.c:354` demands `EINVAL` for 13569465601
seconds:

```c
  puts( "Init: clock_settime - 2400-01-01T00:00:01Z EINVAL" );
  tv.tv_sec = 13569465601;
  tv.tv_nsec = 0;
  errno = 0;
  sc = clock_settime( CLOCK_REALTIME, &tv );
  rtems_test_assert( sc == -1 );
```

That value lies below the new constant.  `clock_settime()` returns 0 and
the assert fails.  The case above it prints
`2400-01-01T00:00:00.999999999Z` and no longer sits at a boundary.  Move
both cases and both messages to the new limit.

## The two bounds still disagree

`_TOD_Validate()` stops at a year.  `_TOD_Is_valid_new_time_of_day()` stops
at a second.  That gap caused this defect, and the branch keeps it.  The
notes of `rtems_clock_set()` name
`2401-01-01T00:00:00.000000000Z` as the latest value which
`clock_settime()` accepts.  The check uses `>`, so the true latest value is
`2401-01-01T00:00:00.999999999Z`.

Close the gap in `cpukit/score/src/coretodcheck.c:54`:

```c
  if ( tod->tv_sec >= TOD_SECONDS_1970_THROUGH_2400 ) {
    return STATUS_INVALID_NUMBER;
  }
```

Both directives then stop at `2400-12-31T23:59:59.999999999Z`.  The macro
name states an exact fact: a value below the constant lies within 1970
through 2400.  The documentation needs one date instead of two.

## `clock.h` states two different limits

The branch updates the notes and leaves the constraint list at
`cpukit/include/rtems/rtems/clock.h:151`:

```
 * - The time of day set by the directive shall be before
 *   2100-01-01T00:00:00.000000000Z.
```

The file contradicts itself.  Both places name the same instant.  With the
check above:

| Place           | Text                                                                                                                                       |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Notes           | Due to implementation constraints, the latest time of day which this directive and the POSIX `clock_settime()` accept is 2400-12-31T23:59:59.999999999Z. |
| Constraint list | The time of day set by the directive shall be before 2401-01-01T00:00:00.000000000Z.                                                       |

The new notes text also drops `2401-01-01:00:00.000000000Z`, which is no
timestamp.  The branch inherited that form from the line it replaced.

## The commit message

The body lists the edits which the diff shows.  State the problem, then the
approach.  One point of the list is also wrong: `spclock_err02` holds the
leap day check of the year 2400 already, at line 132.  The branch keeps
that case and replaces the year 2800 case.

## What the branch gets right beyond the direction

It drops the year 2800, 4000 and 4095 cases of `spclock_err02`.  No
directive accepts those years after the change.  The value 13601088000 is
2401-01-01T00:00:00Z, and 113.4 years of uptime remain before the 34-bit
seconds field wraps.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1484#note_158980
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-97877m52gbhxnif8bx7sbecp6-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260910/74374a37/attachment-0001.htm>