ZFS: clock_t overflow in l2arc_feed_thread

[Bruce Evans]

On Mon, 31 Jan 2011, Artem Belevich wrote:

> On Sun, Jan 30, 2011 at 9:25 PM, Bruce Evans <brde at optusnet.com.au> wrote:
>
>> Also, there must be another bug for overflow to occur after only 24 days.
>> clock_t is only specified for holding statclock ticks, which have a
>> frequency of about 128 Hz, so 32-bit unsigned ints hold 388 days of ticks.
>
> clock_t is used in solaris code to hold LBOLT (rough equivalent of
> *uptime() in FreeBSD). When the code was ported to FreeBSD, LBOLT was
> implemented so that it holds uptime in HZ ticks. HZ happens to be
> 1000, so clock_t as implemented on FreeBSD will overflow in 24 days.

Certainly a bug.  More than 1:
- clock_t is for stathz ticks, but is abused to count hz ticks.
- the type for hz ticks is plain int.  This is even smaller than clock_t
   provided clock_t is correctly unsigned.  It should be a larger type if
   hz is much larger than stathz.  It worked better when hz was a little
   smaller than stathz, as it still needs to be so that it is not too
   easy to hide from the scheduler using timeouts to schedule yourself.
   When hz was 100, timeouts worked for 194 days, but now they only work
   for 24 days.
- neither of these types can represent long times, but the time may be
   a long time and clock_t is abused to represent it.  Plain int64_t
   might work.

Many times are still represented as timevals, and the tvtohz() function is
used to convert them to a timeout in hz ticks without overflow (long times
are clamped to the maximum).

Bruce