Blame dhcp-4.2.4-P1-interval.patch
|
 |
bd413ec |
diff -up dhcp-4.2.4/common/dispatch.c.foo dhcp-4.2.4/common/dispatch.c
|
|
|
bd413ec |
--- dhcp-4.2.4/common/dispatch.c.foo 2012-07-26 21:31:43.875349675 -0500
|
|
|
bd413ec |
+++ dhcp-4.2.4/common/dispatch.c 2012-07-26 21:39:14.961710319 -0500
|
|
|
bd413ec |
@@ -324,7 +324,20 @@ void add_timeout (when, where, what, ref
|
|
|
bd413ec |
q->next = timeouts;
|
|
|
bd413ec |
timeouts = q;
|
|
|
bd413ec |
|
|
|
bd413ec |
- isc_interval_set(&interval, sec & DHCP_SEC_MAX, usec * 1000);
|
|
|
bd413ec |
+ /* isc_time_nowplusinterval() is not safe with 64-bit time_t and will
|
|
|
bd413ec |
+ * return an error for sufficiently large intervals. We have to limit
|
|
|
bd413ec |
+ * the interval to INT_MAX or less to ensure the interval doesn't
|
|
|
bd413ec |
+ * overflow 32 bits, since the returned isc_time_t fields are
|
|
|
bd413ec |
+ * 32-bit unsigned ints.
|
|
|
bd413ec |
+ *
|
|
|
bd413ec |
+ * HACK: The 9 is a magic number of seconds, since some time may have
|
|
|
bd413ec |
+ * gone by since the last call to gettimeofday() and the one in
|
|
|
bd413ec |
+ * isc_time_nowplusinterval().
|
|
|
bd413ec |
+ */
|
|
|
bd413ec |
+ if (sec > TIME_MAX)
|
|
|
bd413ec |
+ sec = TIME_MAX - 9;
|
|
|
bd413ec |
+
|
|
|
bd413ec |
+ isc_interval_set(&interval, sec, usec * 1000);
|
|
|
bd413ec |
status = isc_time_nowplusinterval(&expires, &interval);
|
|
|
bd413ec |
if (status != ISC_R_SUCCESS) {
|
|
|
bd413ec |
/*
|