On Tuesday 24 November 2015 16:44:07 Alison Schofield wrote: > struct timeval will overflow on 32-bit systems in y2038 and is being > removed from the kernel. Replace the use of struct timeval and > do_gettimeofday() with ktime_get_real_seconds() which provides a 64-bit > seconds value and is y2038 safe. > > gdth driver requires changes in two areas: > > 1) gdth_store_event() loads two u32 timestamp fields for ioctl GDTIOCTL_EVENT > > These timestamp fields are part of struct gdth_evt_str used for passing > event data to userspace. At the first instance of an event we do > (first_stamp=last_stamp="current time"). If that same event repeats, > we do (last_stamp="current time") AND increment same_count to indicate > how many times the event has repeated since first_stamp. > > This patch replaces the use of timeval and do_gettimeofday() with > ktime_get_real_seconds() cast to u32 to extend the timestamp fields > to y2106. > > Beyond y2106, the userspace tools (ie. RAID controller monitors) can > work around the time rollover and this driver would still not need to > change. > > Alternative: The alternative approach is to introduce a new ioctl in gdth > with the u32 time fields defined as u64. This would require userspace > changes now, but not in y2106. > > 2) gdth_show_info() calculates elapsed time using u32 first_stamp > > It is adding events with timestamps to a seq_file. Timestamps are > calculated as the "current time" minus the first_stamp. > > This patch replaces the use of timeval and do_gettimeofday() with > ktime_get_real_seconds() cast to u32 to calculate the timestamp. > > This elapsed time calculation is safe even when the time wraps (beyond > y2106) due to how unsigned subtraction works. A comment has been added > to the code to indicate this safety. > > Alternative: This piece itself doesn't warrant an alternative, but > if we do introduce a new structure & ioctl with u64 timestamps, this > would change accordingly. > > Signed-off-by: Alison Schofield <amsfield22@xxxxxxxxx> Reviewed-by: Arnd Bergmann <arnd@xxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
