On 05/30/2016 04:01 AM, Tina Ruchandani wrote:
'struct frame' uses two variables to store the sent timestamp - 'struct timeval' and jiffies. jiffies is used to avoid discrepancies caused by updates to system time. 'struct timeval' uses 32-bit representation for seconds which will overflow in year 2038.
This patch does the following:
- Replace the use of 'struct timeval' and jiffies with struct timespec64,
which provides a 64-bit seconds timestamp and is year 2038 safe.
- timespec64 provides both long range (like jiffies) and high resolution
(like timeval). Using monotonic time (ktime_get_ts64) instead of wall-clock time prevents any discrepancies caused by updates to system time.
The previous attempt at this patch and related discussion is here: https://lists.linaro.org/pipermail/y2038/2015-May/000245.html As noted previously, the existing code is 2038-safe, as it only uses a delta instead of absolute timestamps. However, this patch is part of a larger attempt to remove _all_ instances of 32-bit timekeeping from the kernel (time_t, struct timeval and struct timespec) since we do not know which of the many instances of their usage are buggy.
It is worth noting that there may be a slight performance penalty, due to timespec64 using nanoseconds instead of microseconds. The tsince_hr function contains a 32-bit multiply just like the existing code, but now it also has a 32-bit divide.
Thank you.
I don't think it's a good idea to introduce a performance regression, since there's no safety concern for aoe.
If the concern is that we don't know which users of the 32-bit timestamp are buggy, but we *do* know that this use is OK, then a comment in the source code seems more appropriate.