You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When CONFIG_TIMEOUT_64BIT is y, positive values are relative/delta
timeouts and negative values are absolute timeouts, except
for two special values. -1 is K_WAIT_FOREVER and 0 is K_NO_WAIT.
The reserved value of -1 means INT64_MAX is not a valid argument
to K_TIMEOUT_ABS_TICKS(), but there was no check. If a literal
was passed, a preprocessor/compiler warning would be generated
for overflow, but if a variable was passed as the argument,
then the code would compile but not work correctly since the
absolute timeout would be changed to a relative one. One
example of this is task_wdt_init() if no channels are enabled.
Rather than just fixing task_wdt, and trying to find other cases
in an adhoc way, this CL changes K_TIMEOUT_ABS_TICKS() to
limit the larges value to (INT64_MAX-1). It does so silently,
but given the range of int64_t, there should be no practical
difference.
Also, change the implementation for Z_IS_TIMEOUT_RELATIVE() to
fix the case where INT64_MAX relative timeout was being
improperly reported as being not a relative timeout. This was
again due to the -1 reserved value.
Add some tests for these changes to the timer_api test.
Signed-off-by: Mike J. Chen <mjchen@google.com>
0 commit comments