Clock fuzzing
Hal Murray
halmurray at sonic.net
Mon Jun 24 04:39:17 UTC 2024
Coverity got a little smarter and now reports a couple of cases of
INTEGER_OVERFLOW in code that hasn't changed in a long time.
One of them is in the clock fuzzing code. I propose to eliminate that
feature.
Any objections?
Long story:
That code dates back to the days when clocks were updated off the
scheduler interrupt or something similar so they took big steps. The idea
was to add a random fuzz of up to 1 tick to the time read from the system
to give a better estimate of the time. But then you have to make sure
that time doesn't go backwards. Modern timekeeping has tiny steps. This
code isn't necessary any more. At worst, our code will do a slightly
worse job of timekeeping on old old systems.
Several years ago, I was chasing sloth in the server code. The fuzzing
code was calling a cryptographic random number generator which is pretty
slow. So I added --disable-fuzz
I've been running/testing with it disabled and haven't noticed any
problems.
--
These are my opinions. I hate spam.
More information about the devel
mailing list