> hzto() is a little problematic!

Actually, it's worse.  I happened to be staring at it a minute ago,
and noticed that it's buggy!  C.f.:

        else if (sec <= (LONG_MAX / hz))
                ticks = (sec * hz) +
                    (((unsigned long)usec + (tick - 1)) / tick) + 1;

On LP64 systems, this can't overflow becase sec and hz are both
bounded enough to prevent it.  On ILP32 systems, LONG_MAX is a prime,
and so there's a bit of slop in the multiplication, but it can still
overflow with some precise combinations; e.g. it's easy to see that
with sec=LONG_MAX/hz and usec=999999, it will always overflow.

Since this overflows just slightly, you get a Large Negative Number,
which is in at least some cases noticed by callout_reset() and
adjusted to 1.  I don't see any cases where this would actually
*crash* the kernel, but it would certainly cause anomalous behavior.