Re: [PATCH v2] scsi: gdth: replace struct timeval with ktime_get_real_seconds()

[Arnd Bergmann <arnd@arndb.de>]

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@gmail.com>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038