lkml.org 
[lkml]   [2015]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Y2038] [PATCH v2] scsi: gdth: replace struct timeval with ktime_get_real_seconds()
Date
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>


\
 
 \ /
  Last update: 2015-11-25 10:21    [W:0.201 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site