Re: [Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

On Tue, Jun 21, 2016 at 12:37 PM, Arnd Bergmann wrote: > On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote: >> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller >> wrote: >> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: >> > >> > Hi

Re: [Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote: > On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: > > > > Hi John, > > > >> I don't see in the above an explanation of *why* you're using > >>

Re: [Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller wrote: > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: > > Hi John, > >> I don't see in the above an explanation of *why* you're using >> ktime_get_raw_ns() instead of ktime_get_ns(). > > Could you help me

Re: [Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: Hi John, > I don't see in the above an explanation of *why* you're using > ktime_get_raw_ns() instead of ktime_get_ns(). Could you help me understand what the difference is or point me to some documentation? I understood that we only

[Y2038] [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

As part of the Y2038 development, __getnstimeofday is not supposed to be used any more. It is now replaced with ktime_get_raw_ns. Albeit ktime_get_raw_ns is monotonic compared to __getnstimeofday, this difference is irrelevant as the Jitter RNG uses the time stamp to measure the execution time of

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 10:12:24 schrieb John Stultz: Hi John, > > So this is definitely more clear then what was described earlier, and > worries me because on many x86 machines (though fewer I guess these > days then in the past) the clocksource will often not be the TSC (and > have lower

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

On Tue, Jun 21, 2016 at 9:51 AM, Stephan Mueller wrote: > Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: > > Hi John, > >> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller > wrote: >> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: Hi John, > On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: > > > > Hi John, > > > >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote: > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: > > Hi John, > >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote: >> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: >>

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: Hi John, > On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote: > > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: > >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: > > Compared to the

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote: > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: >> > Compared to the previous __getnstimeofday(), the difference is > > - using "monotonic"

Re: [Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Wednesday, June 8, 2016 10:04:48 PM CEST Deepa Dinamani wrote: > > Signed-off-by: Deepa Dinamani > Cc: Steve French > Cc: linux-c...@vger.kernel.org > Cc: samba-techni...@lists.samba.org > Cc: Joern Engel > Cc: Prasad Joshi

[Y2038] [PATCH 1/9] y2038: remove unneeded ipc uapi header files

Eight architectures contain copies of the original i386 ipcbuf/msgbuf/sembuf/shmbuf header files, which are all identical to the version in uapi/asm-generic. This patch removes the files and replaces them with 'generic-y' statements, to avoid having to modify each copy when we extend sysvipc to

[Y2038] [PATCH v2 02/24] fs: Replace CURRENT_TIME with current_time() for inode timestamps

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. CURRENT_TIME is also not y2038 safe. This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we

[Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. Thanks to Arnd Bergmann for all the guidance and

Re: [Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Thu, Jun 9, 2016 at 1:38 PM, Deepa Dinamani wrote: > > 1. There are a few link, rename functions which assign times like this: > > - inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME; > + inode->i_ctime = dir->i_ctime = dir->i_mtime = >

Re: [Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani wrote: > CURRENT_TIME macro is not appropriate for filesystems as it > doesn't use the right granularity for filesystem timestamps. > Use current_fs_time() instead. Again - using the inode instead fo the syuperblock in tghis

Re: [Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

Hi, GFS2 bits: Acked-by: Steven Whitehouse Steve. ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038

[Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_fs_time() instead. CURRENT_TIME is also not y2038 safe. This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make

Re: [Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Wed, Jun 08, 2016 at 10:04:48PM -0700, Deepa Dinamani wrote: > CURRENT_TIME macro is not appropriate for filesystems as it > doesn't use the right granularity for filesystem timestamps. > Use current_fs_time() instead. > > CURRENT_TIME is also not y2038 safe. > > This is also in preparation

[Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transistion CURRENT_TIME_SEC to use y2038 safe time interfaces. current_fs_time() will also be extended to use superblock range checking parameters

[Y2038] [PATCH 00/21] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. All filesystem timestamps use current_fs_time() for

[Y2038] [PATCH v4 00/25] Convert the posix_clock_operations and k_clock structure to ready for 2038

This patch series changes the 32-bit time types (timespec/itimerspec) to the 64-bit types (timespec64/itimerspec64), since 32-bit time types will break in the year 2038. This patch series introduces new methods with timespec64/itimerspec64 type, and removes the old ones with timespec/itimerspec

[Y2038] [PATCH v5 00/24] Convert the posix_clock_operations and k_clock structure to ready for 2038

This patch series changes the 32-bit time types (timespec/itimerspec) to the 64-bit types (timespec64/itimerspec64), since 32-bit time types will break in the year 2038 on 32bit systems. This patch series introduces new methods with timespec64/itimerspec64 type, and removes the old ones with

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 10:32:23 schrieb Arnd Bergmann: Hi Arnd, > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: > > Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: > > > > Hi Arnd, > > > > > The jent_get_nstime() function uses __getnstimeofday() to get > > >

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: > Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: > > Hi Arnd, > > > The jent_get_nstime() function uses __getnstimeofday() to get > > something similar to a 64-bit nanosecond counter. As we want > > to get rid of struct

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: Hi Arnd, > The jent_get_nstime() function uses __getnstimeofday() to get > something similar to a 64-bit nanosecond counter. As we want > to get rid of struct timespec to fix the y2038 overflow, > this patch changes the code to use