Hi,
setitimer(2) has a one hundred million second upper bound for timers.
Any timer interval larger than this is considered invalid and we set
EINVAL.
There is no longer any reason to use this particular limit. Kclock
timeouts support the full range of a timespec, so we can trivially
increase the upper bound without any practical risk of overflow.
This patch increases the upper bound to UINT_MAX seconds.
Why UINT_MAX? UINT_MAX is the largest possible input to alarm(3). We
could then simplify the alarm(3) manpage and the libc alarm.c code in
a subsequent patch. POSIX says alarm(3) "is always successful". Our
implementation can fail. It would be nicer/simpler if ours were free
of failure modes.
ok?
Index: kern_time.c
===================================================================
RCS file: /cvs/src/sys/kern/kern_time.c,v
retrieving revision 1.153
diff -u -p -r1.153 kern_time.c
--- kern_time.c 11 Jun 2021 16:36:34 -0000 1.153
+++ kern_time.c 11 Jun 2021 17:13:49 -0000
@@ -709,15 +709,16 @@ out:
int
itimerfix(struct itimerval *itv)
{
+ struct timeval max_interval = { .tv_sec = UINT_MAX, .tv_usec = 0 };
struct timeval min_interval = { .tv_sec = 0, .tv_usec = tick };
if (itv->it_value.tv_sec < 0 || !timerisvalid(&itv->it_value))
return EINVAL;
- if (itv->it_value.tv_sec > 100000000)
+ if (timercmp(&itv->it_value, &max_interval, >))
return EINVAL;
if (itv->it_interval.tv_sec < 0 || !timerisvalid(&itv->it_interval))
return EINVAL;
- if (itv->it_interval.tv_sec > 100000000)
+ if (timercmp(&itv->it_interval, &max_interval, >))
return EINVAL;
if (!timerisset(&itv->it_value))
