On Mon, Jun 17, 2019 at 02:14:57PM +0200, Thomas Gleixner wrote: > On Mon, 17 Jun 2019, 维康石 wrote: > > Yes,the >UINT_MAX value can be passed by > > syscall adjtimex->do_adjtimex->__do_adjtimex->process_adjtimex_modes by the > > proper arugments. > > So there is clearly some sanity check missing, but surely not that > type cast.
As the offset is saved in an int (and returned via adjtimex() in the tai field), should be the maximum INT_MAX? We probably also want to avoid overflow in the offset on a leap second and the CLOCK_TAI clock itself, so maybe it would make sense to specify a much smaller maximum like 1000000? Even 1000 should be good enough for near future. Negative values are not allowed anyway. If the Earth's rotation changed significantly (e.g. hitting a very large asteroid), there probably wouldn't be anyone left to care about TAI. -- Miroslav Lichvar
