Messages in this thread | | | Date | Mon, 17 Jun 2019 17:06:35 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH] time: fix a assignment error in ntp module |
| |
Miroslav,
On Mon, 17 Jun 2019, Miroslav Lichvar wrote:
> 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?
Right.
> 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.
Hehehe. I leave it to you to find a sane limit taking all the possible events into account :)
Thanks,
tglx | |