From: Arnd Bergmann <a...@arndb.de> Date: Tue, 7 Nov 2017 11:38:32 +0100
> Timestamps in pktgen are currently retrieved using the deprecated > do_gettimeofday() function that wraps its signed 32-bit seconds in 2038 > (on 32-bit architectures) and requires a division operation to calculate > microseconds. > > The pktgen header is also defined with the same limitations, hardcoding > to a 32-bit seconds field that can be interpreted as unsigned to produce > times that only wrap in 2106. Whatever code reads the timestamps should > be aware of that problem in general, but probably doesn't care too > much as we are mostly interested in the time passing between packets, > and that is correctly represented. > > Using 64-bit nanoseconds would be cheaper and good for 584 years. Using > monotonic times would also make this unambiguous by avoiding the overflow, > but would make it harder to correlate to the times with those on remote > machines. Either approach would require adding a new runtime flag and > implementing the same thing on the remote side, which we probably don't > want to do unless someone sees it as a real problem. Also, this should > be coordinated with other pktgen implementations and might need a new > magic number. > > For the moment, I'm documenting the overflow in the source code, and > changing the implementation over to an open-coded ktime_get_real_ts64() > plus division, so we don't have to look at it again while scanning for > deprecated time interfaces. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Applied to net-next, thanks Arnd.