Re: [Y2038] [PATCH] net: tilegx: use correct timespec64 type

2016-06-17 Thread David Miller
From: Arnd Bergmann Date: Fri, 17 Jun 2016 18:15:30 +0200 > The conversion to the 64-bit time based ptp methods left two instances > of 'struct timespec' in place. This is harmless because 64-bit > architectures define timespec64 as timespec, and this driver is > not used on

Re: [Y2038] [PATCH] ia64: efi: use timespec64 for persistent clock

2016-06-17 Thread Luck, Tony
> Aside from this, we get a little closer to removing the > __weak read_persistent_clock() definition, which relies on > converting all architectures to provide read_persistent_clock64 > instead. > > Signed-off-by: Arnd Bergmann Applied. Thanks -Tony

Re: [Y2038] [PATCH] blktrace: avoid using timespec

2016-06-17 Thread Jens Axboe
On 06/17/2016 05:36 PM, Steven Rostedt wrote: Jens, You want to take this, or do you want me to? I'll add it to my 4.8 tree, thanks Arnd. -- Jens Axboe ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH 15/21] time: Add time64_to_tm()

2016-06-17 Thread Arnd Bergmann
On Friday, June 17, 2016 1:59:06 PM CEST Deepa Dinamani wrote: > On Fri, Jun 17, 2016 at 1:52 PM, John Stultz wrote: > > On Wed, Jun 15, 2016 at 10:44 AM, Deepa Dinamani > > wrote: > >> On Tue, Jun 14, 2016 at 2:18 PM, John Stultz

Re: [Y2038] [PATCH] ALSA: seq_timer: use monotonic times internally

2016-06-17 Thread Takashi Iwai
On Fri, 17 Jun 2016 17:10:32 +0200, Arnd Bergmann wrote: > > The sequencer client manager reports timestamps in units of unsigned > 32-bit seconds/nanoseconds, but that does not suffer from the y2038 > overflow because it stores only the delta since the 'last_update' > time was recorded. > >

Re: [Y2038] [PATCH] timer: avoid using timespec

2016-06-17 Thread John Stultz
On Fri, Jun 17, 2016 at 8:30 AM, Arnd Bergmann wrote: > The tstats_show() function prints a ktime_t variable by converting > it to struct timespec first. The algorithm is ok, but we want to > stop using timespec in general because of the 32-bit time_t > overflow problem. > > This

[Y2038] [PATCH v3] [media] omap3isp: support 64-bit version of omap3isp_stat_data

2016-06-17 Thread Arnd Bergmann
C libraries with 64-bit time_t use an incompatible format for struct omap3isp_stat_data. This changes the kernel code to support either version, by moving over the normal handling to the 64-bit variant, and adding compatiblity code to handle the old binary format with the existing ioctl command

[Y2038] [PATCH] procfs: avoid 32-bit time_t in /proc/*/stat

2016-06-17 Thread Arnd Bergmann
/proc/stat shows (among lots of other things) the current boottime (i.e. number of seconds since boot). While a 32-bit number is sufficient for this particular case, we want to get rid of the 'struct timespec' suffers from a 32-bit overflow in 2038. This changes the code to use a struct

[Y2038] [PATCH] kvm: x86: use getboottime64

2016-06-17 Thread Arnd Bergmann
KVM reads the current boottime value as a struct timespec in order to calculate the guest wallclock time, resulting in an overflow in 2038 on 32-bit systems. The data then gets passed as an unsigned 32-bit number to the guest, and that in turn overflows in 2106. We cannot do much about the

[Y2038] [PATCH] scsi: libfc: fix seconds_since_last_reset calculation

2016-06-17 Thread Arnd Bergmann
The fc_get_host_stats() function contains a complex conversion from jiffies to timespec to seconds. As we try to get rid of uses of struct timespec, we can clean this up and replace it with a simpler computation. Simply dividing the difference in jiffies by HZ is not only much more efficient, it

[Y2038] [PATCH] md: use seconds granularity for error logging

2016-06-17 Thread Arnd Bergmann
The md code stores the exact time of the last error in the last_read_error variable using a timespec structure. It only ever uses the seconds portion of that though, so we can use a scalar for it. There won't be an overflow in 2038 here, because it already used monotonic time and 32-bit is enough

Re: [Y2038] [PATCH] x86: remove unused efi_get_time function

2016-06-17 Thread Ard Biesheuvel
On 17 June 2016 at 16:56, Arnd Bergmann wrote: > Nothing calls the efi_get_time function on x86, but it does suffer > from the 32-bit time_t overflow in 2038. > > This removes the function, we can always put it back in case we need > it later. > > Signed-off-by: Arnd Bergmann

[Y2038] [PATCH] x86: fix unused efi_get_time function

2016-06-17 Thread Arnd Bergmann
Nothing calls the efi_get_time function on x86, but it does suffer from the 32-bit time_t overflow in 2038. To avoid that if anyone starts calling it, this changes the function to use timespec64 and mktime64 instead. Signed-off-by: Arnd Bergmann --- The obvious alternative would