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