Y2038

y2038@lists.linaro.org

1140 discussions

[PATCH 0/3] time: Add y2038 safe struct __kernel_itimerspec

by Deepa Dinamani

The series aims at adding a new y2038-safe struct __kernel_itimerspec. This is intended to replace the struct itimerspec at ABI level. The series is a continuation of efforts to convert all syscalls with time_t or time_t-derived structures to be y2038-safe. Arnd, maybe this series can go along with the rest of syscalls that you have in your y2038 tree? Deepa Dinamani (3): time: Introduce struct __kernel_itimerspec time: Enable get/put_compat_itimerspec64 always time: Change types to new y2038 safe __kernel_itimerspec fs/timerfd.c | 8 ++++---- include/linux/compat.h | 9 --------- include/linux/compat_time.h | 9 +++++++++ include/linux/syscalls.h | 10 +++++----- include/linux/time.h | 4 ++-- include/linux/time64.h | 1 + include/uapi/linux/time.h | 7 +++++++ kernel/compat.c | 29 ----------------------------- kernel/time/posix-timers.c | 12 +++++++----- kernel/time/time.c | 25 +++++++++++++++++++++++-- 10 files changed, 58 insertions(+), 56 deletions(-) base-commit: 4b373f94fee5acf2ff4c1efbb3f702060379df1f -- 2.17.1

7 years, 6 months

[GIT PULL] vfs/y2038: inode timestamps conversion to timespec64

by Arnd Bergmann

The following changes since commit 93b7f7ad2018d2037559b1d0892417864c78b371: skip LAYOUTRETURN if layout is invalid (2018-06-12 08:48:04 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git tags/vfs-timespec64 for you to fetch changes up to e264abeaf9daa3cde9aed8013a6f82b0370425e5: pstore: Remove bogus format string definition (2018-06-14 14:57:24 +0200) ---------------------------------------------------------------- vfs/y2038: inode timestamps conversion to timespec64 This is a late set of changes from Deepa Dinamani doing an automated treewide conversion of the inode and iattr structures from 'timespec' to 'timespec64', to push the conversion from the VFS layer into the individual file systems. There were no conflicts between this and the contents of linux-next until just before the merge window, when we saw multiple problems: - A minor conflict with my own y2038 fixes, which I could address by adding another patch on top here. - One semantic conflict with late changes to the NFS tree. I addressed this by merging Deepa's original branch on top of the changes that now got merged into mainline and making sure the merge commit includes the necessary changes as produced by coccinelle. - A trivial conflict against the removal of staging/lustre. - Multiple conflicts against the VFS changes in the overlayfs tree. These are still part of linux-next, but apparently this is no longer intended for 4.18 [1], so I am ignoring that part. As Deepa writes: The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The series involves the following: 1. Add vfs helper functions for supporting struct timepec64 timestamps. 2. Cast prints of vfs timestamps to avoid warnings after the switch. 3. Simplify code using vfs timestamps so that the actual replacement becomes easy. 4. Convert vfs timestamps to use struct timespec64 using a script. This is a flag day patch. Next steps: 1. Convert APIs that can handle timespec64, instead of converting timestamps at the boundaries. 2. Update internal data structures to avoid timestamp conversions. Thomas Gleixner adds: I think there is no point to drag that out for the next merge window. The whole thing needs to be done in one go for the core changes which means that you're going to play that catchup game forever. Let's get over with it towards the end of the merge window. [1] https://www.spinics.net/lists/linux-fsdevel/msg128294.html ---------------------------------------------------------------- Note: since the conflicting overlayfs changes are still part of linux-next, the linux-next build will fail after this gets merged, unless the overlayfs tree gets dropped or updated to reflect the changes. Arnd Bergmann (2): Merge branch 'vfs_timespec64' of https://github.com/deepa-hub/vfs into vfs-timespec64 pstore: Remove bogus format string definition Deepa Dinamani (6): fs: add timespec64_truncate() lustre: Use long long type to print inode time ceph: make inode time prints to be long long fs: nfs: get rid of memcpys for inode times udf: Simplify calls to udf_disk_stamp_to_time vfs: change inode times to use struct timespec64 Kees Cook (1): pstore: Convert internal records to timespec64 drivers/firmware/efi/efi-pstore.c | 27 ++++---- drivers/staging/lustre/lustre/llite/llite_lib.c | 12 ++-- drivers/staging/lustre/lustre/llite/namei.c | 5 +- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 7 +- drivers/staging/lustre/lustre/mdc/mdc_reint.c | 6 +- drivers/staging/lustre/lustre/obdclass/obdo.c | 6 +- drivers/tty/tty_io.c | 15 ++++- drivers/usb/gadget/function/f_fs.c | 2 +- fs/adfs/inode.c | 7 +- fs/afs/fsclient.c | 2 +- fs/attr.c | 14 ++-- fs/bad_inode.c | 2 +- fs/btrfs/file.c | 6 +- fs/btrfs/inode.c | 8 +-- fs/btrfs/ioctl.c | 4 +- fs/btrfs/root-tree.c | 4 +- fs/btrfs/transaction.c | 2 +- fs/ceph/addr.c | 12 ++-- fs/ceph/cache.c | 4 +- fs/ceph/caps.c | 6 +- fs/ceph/file.c | 6 +- fs/ceph/inode.c | 86 +++++++++++++------------ fs/ceph/mds_client.c | 7 +- fs/ceph/snap.c | 6 +- fs/cifs/cache.c | 4 +- fs/cifs/fscache.c | 8 +-- fs/cifs/inode.c | 26 ++++---- fs/coda/coda_linux.c | 12 ++-- fs/configfs/inode.c | 12 ++-- fs/cramfs/inode.c | 2 +- fs/ext4/ext4.h | 34 ++++++---- fs/ext4/ialloc.c | 4 +- fs/ext4/namei.c | 2 +- fs/f2fs/f2fs.h | 10 ++- fs/f2fs/file.c | 12 ++-- fs/f2fs/inode.c | 12 ++-- fs/f2fs/namei.c | 4 +- fs/fat/inode.c | 20 ++++-- fs/fat/namei_msdos.c | 21 +++--- fs/fat/namei_vfat.c | 22 ++++--- fs/fuse/inode.c | 2 +- fs/gfs2/dir.c | 6 +- fs/gfs2/glops.c | 4 +- fs/hfs/inode.c | 4 +- fs/hfsplus/inode.c | 12 ++-- fs/hostfs/hostfs_kern.c | 12 ++-- fs/inode.c | 58 ++++++++++++----- fs/jffs2/dir.c | 18 +++--- fs/jffs2/file.c | 2 +- fs/jffs2/fs.c | 12 ++-- fs/kernfs/dir.c | 4 +- fs/kernfs/inode.c | 8 +-- fs/locks.c | 2 +- fs/nfs/callback_proc.c | 4 +- fs/nfs/fscache-index.c | 4 +- fs/nfs/fscache.c | 12 ++-- fs/nfs/inode.c | 49 ++++++++------ fs/nfs/nfs2xdr.c | 25 ++++--- fs/nfs/nfs3xdr.c | 8 ++- fs/nfs/nfs4xdr.c | 7 +- fs/nfsd/blocklayout.c | 8 ++- fs/nfsd/nfs3xdr.c | 14 ++-- fs/nfsd/nfs4xdr.c | 7 +- fs/nfsd/nfsxdr.c | 2 +- fs/ntfs/inode.c | 30 ++++----- fs/ocfs2/dlmglue.c | 20 ++++-- fs/ocfs2/file.c | 6 +- fs/orangefs/inode.c | 2 +- fs/orangefs/orangefs-kernel.h | 2 +- fs/overlayfs/inode.c | 2 +- fs/overlayfs/overlayfs.h | 2 +- fs/proc/uptime.c | 2 +- fs/pstore/platform.c | 2 +- fs/pstore/ram.c | 18 +++--- fs/reiserfs/namei.c | 2 +- fs/reiserfs/xattr.c | 4 +- fs/ubifs/dir.c | 4 +- fs/ubifs/file.c | 23 +++---- fs/ubifs/ubifs.h | 2 +- fs/udf/ialloc.c | 4 +- fs/udf/inode.c | 59 +++++++++-------- fs/udf/super.c | 17 +++-- fs/udf/udfdecl.h | 4 +- fs/udf/udftime.c | 9 +-- fs/xfs/xfs_inode.c | 2 +- fs/xfs/xfs_iops.c | 2 +- fs/xfs/xfs_trans_inode.c | 2 +- include/linux/fs.h | 24 +++---- include/linux/pstore.h | 2 +- include/linux/stat.h | 8 +-- 90 files changed, 559 insertions(+), 440 deletions(-)

7 years, 6 months

Important Notification

by Information Update

Dear Recipent , This email address has won Three Million Pounds on the o2 mobile sweepstakes.Please Contact Payment Cordinator Mat on email : mrwest(a)o2loto.co.uk for explanation and payment processing . Yours Faithfully Debbie Spence Cordinator O2 Mobile Promotional Sweepstakes.

7 years, 6 months

vfs_timespec64 merge into v4.18?

by Arnd Bergmann

Hi everyone, As I discussed with Thomas on IRC, I'd still like to try to get Deepa's series merged to have 64-bit inode timestamps in VFS, as a prerequisite to fixing the individual file systems for y2038 as the next step. The orignal tree that I've been testing with is in https://github.com/deepa-hub/vfs vfs_timespec64 (see description at [1] Unfortunately this was never in linux-next so far, so it's definitely against our normal rules, and if there are any objections (or new issues getting found), then we should defer it another merge window. Until very recently, the branch worked fine with both linux-next and 4.17-rc, but with some last minute changes to the NFS and Overlayfs trees, it gained some nasty conflicts. I've merged Trond's NFS branch and Miklos' Overlayfs branches into it, fixed up those conflicts and now uploaded it to my tree at git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git Obviously this will break if either of them rebases their trees once more, in which case I assume Stephen will drop my branch from linux-next. Once those two are merged into mainline and nothing unexpected has come up from linux-next testing, we could either send a pull request to Linus for the merged branch, or regenerate the flag-day patch in it using coccinelle, which should result in identical contents. Arnd [1] https://lkml.org/lkml/2018/5/25/828

7 years, 6 months

[PATCH 1/5] powerpc: always enable RTC_LIB

by Arnd Bergmann

In order to use the rtc_tm_to_time64() and rtc_time64_to_tm() helper functions in later patches, we have to ensure that CONFIG_RTC_LIB is always built-in. Note that this symbol only controls a couple of helper functions, not the actual RTC subsystem, which remains optional and is enabled with CONFIG_RTC_CLASS. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index c32a181a7cbb..de2cda320fdd 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -232,6 +232,7 @@ config PPC select OF_RESERVED_MEM select OLD_SIGACTION if PPC32 select OLD_SIGSUSPEND + select RTC_LIB select SPARSE_IRQ select SYSCTL_EXCEPTION_TRACE select VIRT_TO_BUS if !PPC64 -- 2.9.0

7 years, 6 months

[GIT PULL] Transition vfs to 64-bit timestamps

by Deepa Dinamani

Hi Thomas, This is a pull request for the series that I sent earlier. The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The flag patch applies cleanly. I've not seen the timestamps update logic change often. The series applies cleanly on 4.17-rc6 and linux-next tip (top commit: next-20180517). I'm not sure how to merge this kind of a series with a flag patch. We are targeting 4.18 for this. Let me know if you have other suggestions. The series involves the following: 1. Add vfs helper functions for supporting struct timepec64 timestamps. 2. Cast prints of vfs timestamps to avoid warnings after the switch. 3. Simplify code using vfs timestamps so that the actual replacement becomes easy. 4. Convert vfs timestamps to use struct timespec64 using a script. This is a flag day patch. I've tried to keep the conversions with the script simple, to aid in the reviews. I've kept all the internal filesystem data structures and function signatures the same. Next steps: 1. Convert APIs that can handle timespec64, instead of converting timestamps at the boundaries. 2. Update internal data structures to avoid timestamp conversions. -- Changes from v1: * Fix the pointer bug in the udf patch. * Include Kees's patch for pstore. * Fix hostfs regression found by kbuild bot. The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11: Linux 4.17-rc6 (2018-05-20 15:31:38 -0700) are available in the Git repository at: https://github.com/deepa-hub/vfs vfs_timespec64 for you to fetch changes up to 213ae530f442029284ab6041812df0571ebd9da7: vfs: change inode times to use struct timespec64 (2018-05-25 15:31:14 -0700) ---------------------------------------------------------------- Deepa Dinamani (6): fs: add timespec64_truncate() lustre: Use long long type to print inode time ceph: make inode time prints to be long long fs: nfs: get rid of memcpys for inode times udf: Simplify calls to udf_disk_stamp_to_time vfs: change inode times to use struct timespec64 Kees Cook (1): pstore: Convert internal records to timespec64 drivers/firmware/efi/efi-pstore.c | 27 ++++---- drivers/staging/lustre/lustre/llite/llite_lib.c | 12 ++-- drivers/staging/lustre/lustre/llite/namei.c | 5 +- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 7 +- drivers/staging/lustre/lustre/mdc/mdc_reint.c | 6 +- drivers/staging/lustre/lustre/obdclass/obdo.c | 6 +- drivers/tty/tty_io.c | 15 ++++- drivers/usb/gadget/function/f_fs.c | 2 +- fs/adfs/inode.c | 7 +- fs/afs/fsclient.c | 2 +- fs/attr.c | 14 ++-- fs/bad_inode.c | 2 +- fs/btrfs/file.c | 6 +- fs/btrfs/inode.c | 8 +-- fs/btrfs/ioctl.c | 4 +- fs/btrfs/root-tree.c | 4 +- fs/btrfs/transaction.c | 2 +- fs/ceph/addr.c | 12 ++-- fs/ceph/cache.c | 4 +- fs/ceph/caps.c | 6 +- fs/ceph/file.c | 6 +- fs/ceph/inode.c | 86 +++++++++++++------------ fs/ceph/mds_client.c | 7 +- fs/ceph/snap.c | 6 +- fs/cifs/cache.c | 4 +- fs/cifs/fscache.c | 8 +-- fs/cifs/inode.c | 26 ++++---- fs/coda/coda_linux.c | 12 ++-- fs/configfs/inode.c | 12 ++-- fs/cramfs/inode.c | 2 +- fs/ext4/ext4.h | 34 ++++++---- fs/ext4/ialloc.c | 4 +- fs/ext4/namei.c | 2 +- fs/f2fs/f2fs.h | 10 ++- fs/f2fs/file.c | 12 ++-- fs/f2fs/inode.c | 12 ++-- fs/f2fs/namei.c | 4 +- fs/fat/inode.c | 20 ++++-- fs/fat/namei_msdos.c | 21 +++--- fs/fat/namei_vfat.c | 22 ++++--- fs/fuse/inode.c | 2 +- fs/gfs2/dir.c | 6 +- fs/gfs2/glops.c | 4 +- fs/hfs/inode.c | 4 +- fs/hfsplus/inode.c | 12 ++-- fs/hostfs/hostfs_kern.c | 12 ++-- fs/inode.c | 58 ++++++++++++----- fs/jffs2/dir.c | 18 +++--- fs/jffs2/file.c | 2 +- fs/jffs2/fs.c | 12 ++-- fs/kernfs/dir.c | 4 +- fs/kernfs/inode.c | 8 +-- fs/locks.c | 2 +- fs/nfs/callback_proc.c | 4 +- fs/nfs/fscache-index.c | 4 +- fs/nfs/fscache.c | 12 ++-- fs/nfs/inode.c | 39 ++++++----- fs/nfs/nfs2xdr.c | 25 ++++--- fs/nfs/nfs3xdr.c | 8 ++- fs/nfs/nfs4xdr.c | 7 +- fs/nfsd/blocklayout.c | 8 ++- fs/nfsd/nfs3xdr.c | 14 ++-- fs/nfsd/nfs4xdr.c | 7 +- fs/nfsd/nfsxdr.c | 2 +- fs/ntfs/inode.c | 30 ++++----- fs/ocfs2/dlmglue.c | 20 ++++-- fs/ocfs2/file.c | 6 +- fs/orangefs/inode.c | 2 +- fs/orangefs/orangefs-kernel.h | 2 +- fs/overlayfs/inode.c | 2 +- fs/overlayfs/overlayfs.h | 2 +- fs/proc/uptime.c | 2 +- fs/pstore/platform.c | 2 +- fs/pstore/ram.c | 21 ++++-- fs/reiserfs/namei.c | 2 +- fs/reiserfs/xattr.c | 4 +- fs/ubifs/dir.c | 4 +- fs/ubifs/file.c | 23 +++---- fs/ubifs/ubifs.h | 2 +- fs/udf/ialloc.c | 4 +- fs/udf/inode.c | 59 +++++++++-------- fs/udf/super.c | 17 +++-- fs/udf/udfdecl.h | 4 +- fs/udf/udftime.c | 9 +-- fs/xfs/xfs_inode.c | 2 +- fs/xfs/xfs_iops.c | 2 +- fs/xfs/xfs_trans_inode.c | 2 +- include/linux/fs.h | 24 +++---- include/linux/pstore.h | 2 +- include/linux/stat.h | 8 +-- 90 files changed, 558 insertions(+), 434 deletions(-) -- 2.17.0

7 years, 6 months

[PATCH] pstore: Remove bogus format string definition

by Arnd Bergmann

The pstore conversion to timespec64 introduces its own method of passing seconds into sscanf() and sprintf() type functions to work around the timespec64 definition on 64-bit systems that redefine it to 'timespec'. That hack is now finally getting removed, but that means we get a (harmless) warning once both patches are merged: fs/pstore/ram.c: In function 'ramoops_read_kmsg_hdr': fs/pstore/ram.c:39:29: error: format '%ld' expects argument of type 'long int *', but argument 3 has type 'time64_t *' {aka 'long long int *'} [-Werror=format=] #define RAMOOPS_KERNMSG_HDR "====" ^~~~~~ fs/pstore/ram.c:167:21: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR' This removes the pstore specific workaround and uses the same method that we have in place for all other functions that print a timespec64. Related to this, I found that the kasprintf() output contains an incorrect nanosecond values for any number starting with zeroes, and I adapt the format string accordingly. Link: https://lkml.org/lkml/2018/5/19/115 Link: https://lkml.org/lkml/2018/5/16/1080 Fixes: 0f0d83b99ef7 ("pstore: Convert internal records to timespec64") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- fs/pstore/ram.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 69e893076ab7..bbd1e357c23d 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -38,11 +38,6 @@ #define RAMOOPS_KERNMSG_HDR "====" #define MIN_MEM_SIZE 4096UL -#if __BITS_PER_LONG == 64 -# define TVSEC_FMT "%ld" -#else -# define TVSEC_FMT "%lld" -#endif static ulong record_size = MIN_MEM_SIZE; module_param(record_size, ulong, 0400); @@ -164,15 +159,15 @@ static int ramoops_read_kmsg_hdr(char *buffer, struct timespec64 *time, char data_type; int header_length = 0; - if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n%n", - &time->tv_sec, &time->tv_nsec, &data_type, + if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu-%c\n%n", + (time64_t *)&time->tv_sec, &time->tv_nsec, &data_type, &header_length) == 3) { if (data_type == 'C') *compressed = true; else *compressed = false; - } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu\n%n", - &time->tv_sec, &time->tv_nsec, + } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu\n%n", + (time64_t *)&time->tv_sec, &time->tv_nsec, &header_length) == 2) { *compressed = false; } else { @@ -367,8 +362,8 @@ static size_t ramoops_write_kmsg_hdr(struct persistent_ram_zone *prz, char *hdr; size_t len; - hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n", - record->time.tv_sec, + hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR "%lld.%06lu-%c\n", + (time64_t)record->time.tv_sec, record->time.tv_nsec / 1000, record->compressed ? 'C' : 'D'); WARN_ON_ONCE(!hdr); -- 2.9.0

7 years, 6 months

[PATCH 1/3] rtc: vr41xx: remove mktime usage

by Arnd Bergmann

This driver uses mktime() and rtc_time_to_tm() to convert between time values. This works fine on 64-bit kernels over the whole supported range, and the vr41xx chip is a 64-bit MIPS implementation, but it is inconsistent because it doesn't do the same thing on 32-bit kernels that overflow in 2106 or 2038. Changing it to use mktime64/rtc_time64_to_tm() should have no visible impact on vr41xx but gets us closer to removing the 32-bit interfaces. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/rtc/rtc-vr41xx.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/rtc/rtc-vr41xx.c b/drivers/rtc/rtc-vr41xx.c index 7ce22967fd16..480cffe8d321 100644 --- a/drivers/rtc/rtc-vr41xx.c +++ b/drivers/rtc/rtc-vr41xx.c @@ -88,7 +88,7 @@ static unsigned int alarm_enabled; static int aie_irq; static int pie_irq; -static inline unsigned long read_elapsed_second(void) +static inline time64_t read_elapsed_second(void) { unsigned long first_low, first_mid, first_high; @@ -105,10 +105,10 @@ static inline unsigned long read_elapsed_second(void) } while (first_low != second_low || first_mid != second_mid || first_high != second_high); - return (first_high << 17) | (first_mid << 1) | (first_low >> 15); + return ((u64)first_high << 17) | (first_mid << 1) | (first_low >> 15); } -static inline void write_elapsed_second(unsigned long sec) +static inline void write_elapsed_second(time64_t sec) { spin_lock_irq(&rtc_lock); @@ -121,22 +121,22 @@ static inline void write_elapsed_second(unsigned long sec) static int vr41xx_rtc_read_time(struct device *dev, struct rtc_time *time) { - unsigned long epoch_sec, elapsed_sec; + time64_t epoch_sec, elapsed_sec; - epoch_sec = mktime(epoch, 1, 1, 0, 0, 0); + epoch_sec = mktime64(epoch, 1, 1, 0, 0, 0); elapsed_sec = read_elapsed_second(); - rtc_time_to_tm(epoch_sec + elapsed_sec, time); + rtc_time64_to_tm(epoch_sec + elapsed_sec, time); return 0; } static int vr41xx_rtc_set_time(struct device *dev, struct rtc_time *time) { - unsigned long epoch_sec, current_sec; + time64_t epoch_sec, current_sec; - epoch_sec = mktime(epoch, 1, 1, 0, 0, 0); - current_sec = mktime(time->tm_year + 1900, time->tm_mon + 1, time->tm_mday, + epoch_sec = mktime64(epoch, 1, 1, 0, 0, 0); + current_sec = mktime64(time->tm_year + 1900, time->tm_mon + 1, time->tm_mday, time->tm_hour, time->tm_min, time->tm_sec); write_elapsed_second(current_sec - epoch_sec); @@ -165,11 +165,11 @@ static int vr41xx_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *wkalrm) static int vr41xx_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *wkalrm) { - unsigned long alarm_sec; + time64_t alarm_sec; struct rtc_time *time = &wkalrm->time; - alarm_sec = mktime(time->tm_year + 1900, time->tm_mon + 1, time->tm_mday, - time->tm_hour, time->tm_min, time->tm_sec); + alarm_sec = mktime64(time->tm_year + 1900, time->tm_mon + 1, time->tm_mday, + time->tm_hour, time->tm_min, time->tm_sec); spin_lock_irq(&rtc_lock); -- 2.9.0

7 years, 7 months

[PATCH 0/6] Transition vfs to 64-bit timestamps

by Deepa Dinamani

The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The series involves the following: 1. Add vfs helper functions for supporting struct timepec64 timestamps. 2. Cast prints of vfs timestamps to avoid warnings after the switch. 3. Simplify code using vfs timestamps so that the actual replacement becomes easy. 4. Convert vfs timestamps to use struct timespec64 using a script. This is a flag day patch. I've tried to keep the conversions with the script simple, to aid in the reviews. I've kept all the internal filesystem data structures and function signatures the same. Next steps: 1. Convert APIs that can handle timespec64, instead of converting timestamps at the boundaries. 2. Update internal data structures to avoid timestamp conversions. Deepa Dinamani (6): fs: add timespec64_truncate() lustre: Use long long type to print inode time ceph: make inode time prints to be long long fs: nfs: get rid of memcpys for inode times udf: Simplify calls to udf_disk_stamp_to_time vfs: change inode times to use struct timespec64 .../staging/lustre/lustre/llite/llite_lib.c | 12 +-- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 7 +- drivers/staging/lustre/lustre/mdc/mdc_reint.c | 6 +- drivers/staging/lustre/lustre/obdclass/obdo.c | 6 +- drivers/tty/tty_io.c | 15 +++- drivers/usb/gadget/function/f_fs.c | 2 +- fs/adfs/inode.c | 7 +- fs/afs/fsclient.c | 2 +- fs/attr.c | 14 +-- fs/bad_inode.c | 2 +- fs/btrfs/file.c | 6 +- fs/btrfs/inode.c | 8 +- fs/btrfs/ioctl.c | 4 +- fs/btrfs/root-tree.c | 4 +- fs/btrfs/transaction.c | 2 +- fs/ceph/addr.c | 12 +-- fs/ceph/cache.c | 4 +- fs/ceph/caps.c | 6 +- fs/ceph/file.c | 6 +- fs/ceph/inode.c | 86 ++++++++++--------- fs/ceph/mds_client.c | 7 +- fs/ceph/snap.c | 6 +- fs/cifs/cache.c | 4 +- fs/cifs/fscache.c | 8 +- fs/cifs/inode.c | 26 +++--- fs/coda/coda_linux.c | 12 +-- fs/configfs/inode.c | 12 +-- fs/cramfs/inode.c | 2 +- fs/ext4/ext4.h | 34 +++++--- fs/ext4/ialloc.c | 4 +- fs/ext4/namei.c | 2 +- fs/f2fs/f2fs.h | 10 ++- fs/f2fs/file.c | 12 +-- fs/f2fs/inode.c | 12 +-- fs/f2fs/namei.c | 4 +- fs/fat/inode.c | 20 +++-- fs/fat/namei_msdos.c | 21 +++-- fs/fat/namei_vfat.c | 22 +++-- fs/fuse/inode.c | 2 +- fs/gfs2/dir.c | 6 +- fs/gfs2/glops.c | 4 +- fs/hfs/inode.c | 4 +- fs/hfsplus/inode.c | 12 +-- fs/hostfs/hostfs_kern.c | 6 +- fs/inode.c | 58 +++++++++---- fs/jffs2/dir.c | 18 ++-- fs/jffs2/file.c | 2 +- fs/jffs2/fs.c | 12 +-- fs/kernfs/dir.c | 4 +- fs/kernfs/inode.c | 8 +- fs/locks.c | 2 +- fs/nfs/callback_proc.c | 4 +- fs/nfs/fscache-index.c | 4 +- fs/nfs/fscache.c | 12 +-- fs/nfs/inode.c | 39 +++++---- fs/nfs/nfs2xdr.c | 25 +++--- fs/nfs/nfs3xdr.c | 8 +- fs/nfs/nfs4xdr.c | 7 +- fs/nfsd/blocklayout.c | 8 +- fs/nfsd/nfs3xdr.c | 14 +-- fs/nfsd/nfs4xdr.c | 7 +- fs/nfsd/nfsxdr.c | 2 +- fs/ntfs/inode.c | 30 +++---- fs/ocfs2/dlmglue.c | 20 +++-- fs/ocfs2/file.c | 6 +- fs/orangefs/inode.c | 2 +- fs/orangefs/orangefs-kernel.h | 2 +- fs/overlayfs/inode.c | 2 +- fs/overlayfs/overlayfs.h | 2 +- fs/proc/uptime.c | 2 +- fs/pstore/inode.c | 2 +- fs/reiserfs/namei.c | 2 +- fs/reiserfs/xattr.c | 4 +- fs/ubifs/dir.c | 4 +- fs/ubifs/file.c | 23 ++--- fs/ubifs/ubifs.h | 2 +- fs/udf/ialloc.c | 4 +- fs/udf/inode.c | 59 +++++++------ fs/udf/super.c | 16 ++-- fs/udf/udfdecl.h | 4 +- fs/udf/udftime.c | 9 +- fs/xfs/xfs_inode.c | 2 +- fs/xfs/xfs_iops.c | 2 +- fs/xfs/xfs_trans_inode.c | 2 +- include/linux/fs.h | 24 +++--- include/linux/stat.h | 8 +- 86 files changed, 522 insertions(+), 408 deletions(-) base-commit: 1c25af77721fa388cb01b2afc7fbe4f1f98685fd -- 2.17.0 CC: andreas.dilger(a)intel.com Cc: <anton(a)tuxera.com> Cc: <balbi(a)kernel.org> Cc: <bfields(a)fieldses.org> Cc: ceph-devel(a)vger.kernel.org Cc: <darrick.wong(a)oracle.com> Cc: <dhowells(a)redhat.com> Cc: <dsterba(a)suse.com> Cc: <dwmw2(a)infradead.org> Cc: <hch(a)lst.de> Cc: <hirofumi(a)mail.parknet.co.jp> Cc: <hubcap(a)omnibond.com> Cc: <jack(a)suse.com> Cc: jack(a)suse.com Cc: <jaegeuk(a)kernel.org> Cc: <jaharkes(a)cs.cmu.edu> Cc: <jslaby(a)suse.com> Cc: <keescook(a)chromium.org> Cc: <mark(a)fasheh.com> Cc: <miklos(a)szeredi.hu> Cc: <nico(a)linaro.org> Cc: <reiserfs-devel(a)vger.kernel.org> Cc: <richard(a)nod.at> Cc: <sage(a)redhat.com> Cc: <sfrench(a)samba.org> Cc: <swhiteho(a)redhat.com> Cc: <tj(a)kernel.org> Cc: <trond.myklebust(a)primarydata.com> Cc: trond.myklebust(a)primarydata.com Cc: <tytso(a)mit.edu> Cc: <viro(a)zeniv.linux.org.uk> Cc: zyan(a)redhat.com

7 years, 7 months

Point Of Sale Software Users List.

by jacinta.martin＠collabratesuite.com

<div dir="ltr">Hi, Hope this note finds you well! Would you be interested in Point Of Sale Software Users List? We are a Global Technology User’s List Provider’s with 90 Million Plus data and counting. It is good if you keep track of all your competitors' movements and their campaign strategies. But do not make their strategies of your own; you can never beat them that way. Even if the industry is the same, each organization has some specific business goals in mind that requires a campaign-plan that is different from others. Considering the fact that data requirement for every marketer will be non-identical as per their campaign planning, we at first consult with our clients to understand their strategies and then tailor personalized list of companies using POS software accordingly. Do not hesitate to take the smart step for improving your business. Deliver highly targeted campaign to your customers and prospects using the comprehensive Retail Management (POS) Software user group’s data, drive the right traffic to your website and generate quality leads through targeted b2b marketing. By partnering with us you can obtain an effective email list of Point of Sale software customers, where each record comes with full contact name, complete postal address, mobile telephone number and email addresses, and much more. Please let us know your targeted criteria and geography to provide you with detailed information for your review. Let me know your thoughts! Thanks, Jacinta Martin Senior Database Executive To “opt out” response not interested </div>  <a style='display: block; margin: 32px 0 40px 0; padding: 10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and email marketing software for Gmail.</a>

7 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038