[Y2038] [PATCH v3 24/24] time: Delete CURRENT_TIME_SEC

2016-06-25 Thread Deepa Dinamani
All uses of CURRENT_TIME_SEC macro have been replaced by other time functions. This macro is also not y2038 safe. And, all its use cases can be fulfilled by y2038 safe ktime_get_* variants. Signed-off-by: Deepa Dinamani Cc: John Stultz Cc: Thomas

[Y2038] [PATCH v3 19/24] fs: nfs: Make nfs boot time y2038 safe

2016-06-25 Thread Deepa Dinamani
boot_time is represented as a struct timespec. struct timespec and CURRENT_TIME are not y2038 safe. Overall, the plan is to use timespec64 and ktime_t for all internal kernel representation of timestamps. CURRENT_TIME will also be removed. boot_time is used to construct the nfs client boot

[Y2038] [PATCH v3 22/24] fs: ceph: Replace current_fs_time for request stamp

2016-06-25 Thread Deepa Dinamani
The current_fs_time() api is being changed to use vfs struct inode* as an argument instead of struct super_block*. Set the new mds client request r_stamp field using ktime_get_real_ts() instead of using current_fs_time(). Also, since r_stamp is used as mtime on the server, use timespec_trunc()

[Y2038] [PATCH v3 23/24] time: Delete current_fs_time() function

2016-06-25 Thread Deepa Dinamani
All uses of the current_fs_time() function have been replaced by other time interfaces. And, its use cases can be fulfilled by current_time() or ktime_get_* variants. Signed-off-by: Deepa Dinamani Cc: John Stultz Cc: Thomas Gleixner

[Y2038] [PATCH v3 18/24] audit: Use timespec64 to represent audit timestamps

2016-06-25 Thread Deepa Dinamani
struct timespec is not y2038 safe. Audit timestamps are recorded in string format into an audit buffer for a given context. These mark the entry timestamps for the syscalls. Use y2038 safe struct timespec64 to represent the times. The log strings can handle this transition as strings can hold upto

[Y2038] [PATCH v3 20/24] block: Replace CURRENT_TIME with ktime_get_real_ts

2016-06-25 Thread Deepa Dinamani
CURRENT_TIME is not y2038 safe. The macro will be deleted and all the references to it will be replaced by ktime_get_* apis. struct timespec is also not y2038 safe. Retain timespec for timestamp representation here as ceph uses it internally everywhere. These references will be changed to use

[Y2038] [PATCH v3 17/24] fs: ocfs2: Replace CURRENT_TIME with ktime_get_real_seconds()

2016-06-25 Thread Deepa Dinamani
CURRENT_TIME is not y2038 safe. Use y2038 safe ktime_get_real_seconds() here for timestamps. struct heartbeat_block's hb_seq and deletetion time are already 64 bits wide and accommodate times beyond y2038. Signed-off-by: Deepa Dinamani Cc: Mark Fasheh

[Y2038] [PATCH v3 15/24] drivers: staging: lustre: Replace CURRENT_TIME with current_time()

2016-06-25 Thread Deepa Dinamani
CURRENT_TIME macro is not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Use current_time() instead. This is also in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. As part of the effort

[Y2038] [PATCH v3 16/24] fs: ocfs2: Use time64_t to represent orphan scan times

2016-06-25 Thread Deepa Dinamani
struct timespec is not y2038 safe. Use time64_t which is y2038 safe to represent orphan scan times. time64_t is sufficient here as only the seconds delta times are relevant. Also use appropriate time functions that return time in time64_t format. Time functions now return monotonic time instead

[Y2038] [PATCH v3 10/24] fs: udf: Replace CURRENT_TIME with current_time()

2016-06-25 Thread Deepa Dinamani
CURRENT_TIME is not y2038 safe. CURRENT_TIME macro is also not appropriate for filesystems as it doesn't use the right granularity for filesystem timestamps. Logical Volume Integrity format is described to have the same timestamp format for "Recording Date and time" as the other

[Y2038] [PATCH v3 04/24] fs: Replace CURRENT_TIME_SEC with current_time() for inode timestamps

2016-06-25 Thread Deepa Dinamani
CURRENT_TIME_SEC is not y2038 safe. current_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_time() will also be extended to use superblock range checking parameters when

[Y2038] [PATCH v3 09/24] fs: btrfs: Use ktime_get_real_ts for root ctime

2016-06-25 Thread Deepa Dinamani
btrfs_root_item maintains the ctime for root updates. This is not part of vfs_inode. Since current_time() uses struct inode* as an argument as Linus suggested, this cannot be used to update root times unless, we modify the signature to use inode. Since btrfs uses nanosecond time granularity, it

[Y2038] [PATCH v3 08/24] fs: ubifs: Replace CURRENT_TIME_SEC with current_time

2016-06-25 Thread Deepa Dinamani
CURRENT_TIME_SEC is not y2038 safe. current_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transition CURRENT_TIME_SEC to use y2038 safe time interfaces. current_time() returns timestamps according to the granularities set in the inode's

[Y2038] [PATCH v3 07/24] fs: ext4: Use current_time() for inode timestamps

2016-06-25 Thread Deepa Dinamani
CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe. current_time() will be transitioned to be y2038 safe along with vfs. current_time() returns timestamps according to the granularities set in the super_block. The granularity check in ext4_current_time() to call current_time() or

[Y2038] [PATCH v3 06/24] fs: jfs: Replace CURRENT_TIME_SEC by current_time()

2016-06-25 Thread Deepa Dinamani
jfs uses nanosecond granularity for filesystem timestamps. Only this assignment is not using nanosecond granularity. Use current_time() to get the right granularity. Signed-off-by: Deepa Dinamani Cc: Dave Kleikamp Cc:

[Y2038] [PATCH v3 01/24] vfs: Add current_time() api

2016-06-25 Thread Deepa Dinamani
current_fs_time() is used for inode timestamps. Change the signature of the function to take inode pointer instead of superblock as per Linus's suggestion. Also, move the api under vfs as per the discussion on the thread: https://lkml.org/lkml/2016/6/9/36 . As per Arnd's suggestion on the