Y2038

y2038@lists.linaro.org

1132 discussions

[PATCH] fs: btrfs: Use ktime_get_real_ts for root ctime

by 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 can also use ktime_get_real_ts directly to obtain timestamp for the root. It is necessary to use the timespec time api here because the same btrfs_set_stack_timespec_*() apis are used for vfs inode times as well. These can be transitioned to using timespec64 when btrfs internally changes to use timespec64 as well. Signed-off-by: Deepa Dinamani <deepa.kernel(a)gmail.com> Cc: Chris Mason <clm(a)fb.com> Cc: David Sterba <dsterba(a)suse.com> Cc: Josef Bacik <jbacik(a)fb.com> Cc: linux-btrfs(a)vger.kernel.org --- Changes from previous version: * Separated from the current_time() api series. * Moved ktime_get_real_ts() outside of spin lock. fs/btrfs/root-tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c index 0912960..17e5a5f 100644 --- a/fs/btrfs/root-tree.c +++ b/fs/btrfs/root-tree.c @@ -505,8 +505,9 @@ void btrfs_update_root_times(struct btrfs_trans_handle *trans, struct btrfs_root *root) { struct btrfs_root_item *item = &root->root_item; - struct timespec ct = current_fs_time(root->fs_info->sb); + struct timespec ct; + ktime_get_real_ts(&ct); spin_lock(&root->root_item_lock); btrfs_set_root_ctransid(item, trans->transid); btrfs_set_stack_timespec_sec(&item->ctime, ct.tv_sec); -- 2.7.4

8 years, 7 months

[PATCH] fs: cifs: Replace CURRENT_TIME by get_seconds

by Deepa Dinamani

This is in preparation for the change that transitions filesystem timestamps to use 64 bit time and hence make them y2038 safe. CURRENT_TIME macro will be deleted before merging the aforementioned patch. Filesystems will use current_time() instead of CURRENT_TIME. Use ktime_get_real_seconds() here as this is not filesystem time. Only the seconds portion of the timestamp is necessary for timezone calculation using server time. Assume that the difference between server and client times lie in the range INT_MIN..INT_MAX. This is valid because this is the difference between current times between server and client, and the largest timezone difference is in the range of one day. All cifs timestamps currently use timespec internally. This timestamp can also be transitioned into using timespec64 when all other timestamps for cifs is transitioned to use timespec64. Signed-off-by: Deepa Dinamani <deepa.kernel(a)gmail.com> Reviewed-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Steve French <sfrench(a)samba.org> --- fs/cifs/cifssmb.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index d47197e..6c666a3 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -478,14 +478,14 @@ decode_lanman_negprot_rsp(struct TCP_Server_Info *server, NEGOTIATE_RSP *pSMBr) * this requirement. */ int val, seconds, remain, result; - struct timespec ts, utc; - utc = CURRENT_TIME; + struct timespec ts; + unsigned long utc = ktime_get_real_seconds(); ts = cnvrtDosUnixTm(rsp->SrvTime.Date, rsp->SrvTime.Time, 0); cifs_dbg(FYI, "SrvTime %d sec since 1970 (utc: %d) diff: %d\n", - (int)ts.tv_sec, (int)utc.tv_sec, - (int)(utc.tv_sec - ts.tv_sec)); - val = (int)(utc.tv_sec - ts.tv_sec); + (int)ts.tv_sec, (int)utc, + (int)(utc - ts.tv_sec)); + val = (int)(utc - ts.tv_sec); seconds = abs(val); result = (seconds / MIN_TZ_ADJ) * MIN_TZ_ADJ; remain = seconds % MIN_TZ_ADJ; -- 2.7.4

8 years, 7 months

[PATCH] fs: cifs: Replace CURRENT_TIME with ktime_get_real_ts()

by Deepa Dinamani

This is in preparation for the patch that transitions vfs timestamps to use 64 bit time and hence make them y2038 safe. CURRENT_TIME macro will be deleted before merging the aforementioned patch. Filesystem times will use current_fs_time() instead of CURRENT_TIME. Use ktime_get_real_ts() here as this is not filesystem time. ktime_get_real_ts() returns the timestamp in ns which can be used to calculate network time for NTLMv2 authentication timestamp. All cifs timestamps currently use timespec internally. This timestamp can also be transitioned into using timespec64 when all other timestamps for cifs is transitioned to use timespec64. Signed-off-by: Deepa Dinamani <deepa.kernel(a)gmail.com> Reviewed-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Steve French <sfrench(a)samba.org> --- fs/cifs/cifsencrypt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c index 8347c90..fd01bf0 100644 --- a/fs/cifs/cifsencrypt.c +++ b/fs/cifs/cifsencrypt.c @@ -471,6 +471,7 @@ find_timestamp(struct cifs_ses *ses) unsigned char *blobptr; unsigned char *blobend; struct ntlmssp2_name *attrptr; + struct timespec ts; if (!ses->auth_key.len || !ses->auth_key.response) return 0; @@ -495,7 +496,8 @@ find_timestamp(struct cifs_ses *ses) blobptr += attrsize; /* advance attr value */ } - return cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME)); + ktime_get_real_ts(&ts); + return cpu_to_le64(cifs_UnixTimeToNT(ts)); } static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash, -- 2.7.4

8 years, 7 months

[PATCH] fs: ufs: Use ktime_get_real_ts64() for birthtime

by Deepa Dinamani

CURRENT_TIME is not y2038 safe. Replace it with ktime_get_real_ts64(). Inode time formats are already 64 bit long and accommodates time64_t. Signed-off-by: Deepa Dinamani <deepa.kernel(a)gmail.com> Cc: Evgeniy Dushistov <dushistov(a)mail.ru> --- fs/ufs/ialloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/ufs/ialloc.c b/fs/ufs/ialloc.c index fd0203c..876a478 100644 --- a/fs/ufs/ialloc.c +++ b/fs/ufs/ialloc.c @@ -176,6 +176,7 @@ struct inode *ufs_new_inode(struct inode *dir, umode_t mode) struct ufs_cg_private_info * ucpi; struct ufs_cylinder_group * ucg; struct inode * inode; + struct timespec64 ts; unsigned cg, bit, i, j, start; struct ufs_inode_info *ufsi; int err = -ENOSPC; @@ -323,8 +324,9 @@ cg_found: lock_buffer(bh); ufs2_inode = (struct ufs2_inode *)bh->b_data; ufs2_inode += ufs_inotofsbo(inode->i_ino); - ufs2_inode->ui_birthtime = cpu_to_fs64(sb, CURRENT_TIME.tv_sec); - ufs2_inode->ui_birthnsec = cpu_to_fs32(sb, CURRENT_TIME.tv_nsec); + ktime_get_real_ts64(&ts); + ufs2_inode->ui_birthtime = cpu_to_fs64(sb, ts.tv_sec); + ufs2_inode->ui_birthnsec = cpu_to_fs32(sb, ts.tv_nsec); mark_buffer_dirty(bh); unlock_buffer(bh); if (sb->s_flags & MS_SYNCHRONOUS) -- 2.7.4

8 years, 7 months

Re: [Y2038] Fourth draft of the Y2038 design document

by Arnd Bergmann

On Wednesday, June 22, 2016 12:58:38 AM CEST Albert ARIBAUD wrote: > Hi all, > > I have produced a fourth draft of what will eventually become the Y2038 > design document: > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=83 > > Relative to the previous draft: > > * the scope clarifies that *only* Y2038 is considered, and no other > doomsday such as Y2106 or Y9999; > > * all types directly or indirectly derived from time_t are now listed; > > * all APIs using these types are now listed; > > * all functions which use time_t internally are now listed; > > * also listed are types and APIs related to time but which are > Y2038-safe (even though they might be unsafe for some other > doomsday, e.g. struct rpc_timeval being Y2106-unsafe). > > As always, comments welcome. I've cross-checked your list of data structures with the one I have for the kernel at https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T… I noticed 'struct sysinfo' as another interface that holds a time, even though this is documented as 'long' and I concluded that we won't need to change it, that should probably be documented. 'struct rusage' is also interesting, as there is no overflow in 2038, but instead it could overflow on large machines (hundreds of CPUs) with very long-running tasks (months), so I'm unsure how to treat that from the kernel side. It's also one of very few kernel interfaces using 'timeval' rather than 'timespec' (we generally replaced the other ones). My current kernel patch series changes rusage by using 64-bit fields for everything, with the intention of having the same binary layout for 32-bit and 64-bit processes, and reusing the 64-bit syscall entry point for compat mode (running 32-bit tasks on a 64-bit kernel). Does that work for you? I think we should expand the ioctl section a bit: I can do most of it in the kernel, but need help from glibc for a few things in which we need to agree on calling conventions. Here is what I'd suggest having in the document, feel free to take that into your document or edit as you wish: == IOCTLs and Y2038 == Some Linux IOCTLs may be Y2038-unsafe, or use types defined by glibc that do not match the kernel internal types. Known important cases are: - An ioctl command number is defined using the _IOR/_IOW/_IORW macros by the kernel with a structure whose size changes based on glibc's time_t. The kernel can handle these transparently by implementing handlers for both command numbers with the correct structure format. - The binary ABI changes based on the glibc time_t type, but the command number does not change. In this case, the kernel header files defining the data structure will check the "__USE_TIME_BITS64" macro [do we need a new macro for the kernel headers?] to provide a different command number for the new data structure layout. glibc will define this macro at an appropriate location [where?] to make it visible before including kernel header files. - An ioctl command passes time information in a structure that is not based on time_t but another integer type that does not get changed. The kernel header files will provide both a new structure layout and command number when "__USE_TIME_BITS64" is set. [I can find examples for ioctl commands in each of those categories if needed.] == Socket options == Like ioctl(), setsockopt()/getsockopt() has a few interfaces that are passing time data: SO_TIMESTAMP/SO_TIMESTAMPNS/SO_TIMESTAMPING: These enable the timestamping infrastructure for a socket, which will consecutively return data to user space using "cmsg" data on the socket. The kernel does not know the layout of 'struct timespec' and 'struct timeval' when filling the cmsg data, so we need to define new binary values for the three flags, which then get used if __USE_TIME_BITS64 is set. SO_RCVTIMEO/SO_SNTTIMEO: These pass a 'struct timeval' and a length. Assuming that the 'optlen' argument of the setsockopt syscall always matches the size of 'struct timeval', the kernel will be able to access the data in the same format that was passed by glibc. [alternatively, we could handle this the same way as SO_TIMESTAMP*, using new numbers for the flags]. [end quote] Regarding the "Support for non-Y2038-safe kernels" section, I'm not sure if that can work at all: A kernel that does not have the appropriate system calls will also not have the handlers for a lot of the ioctl commands and possibly other interfaces that rely on a specific structure layout. If we can instead enforce that __USE_TIME_BITS64 is only set with a minimal version of kernel headers and that it implies binary compatibility with no older kernel version, we could avoid those problems. On your note "The implementation needs further thinking about, as application code defining _TIME_BITS=64 and gets built against new kernel headers and old GLIBC headers, then GLIBC will use 32-bit time_t and kernel will expect 64-bit time_t, and there is no way to ensure detection of this case.", I think that is covered by having the kernel headers check __USE_TIME_BITS64 instead of _TIME_BITS=64, as I described above. Arnd

8 years, 7 months

[PATCH v5 0/5] Introduce current_time() api

by Deepa Dinamani

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 discussions. Patches 2-4 were mostly generated using coccinelle scripts. All filesystem timestamps use current_fs_time() for right granularity as mentioned in the respective commit texts of patches. This has a changed signature, renamed to current_time() and moved to the fs/inode.c. This series also serves as a preparatory series to transition vfs to 64 bit timestamps as outlined here: https://lkml.org/lkml/2016/2/12/104 . As per Linus's suggestion in https://lkml.org/lkml/2016/5/24/663 , all the inode timestamp changes have been squashed into a single patch. Also, current_time() now is used as a single generic vfs filesystem timestamp api. It also takes struct inode* as argument instead of struct super_block*. Posting all patches together in a bigger series so that the big picture is clear. As per the suggestion in https://lwn.net/Articles/672598/, CURRENT_TIME macro bug fixes are being handled in a series separate from transitioning vfs to use 64 bit timestamps. Changes from v4: * Keeping only api introduction and the generic coccinelle patches in the series. * Individual patches will be sent to respective maintainers as suggested by greg: https://lkml.org/lkml/2016/8/15/470 Changes from v3: * Rebased to 4.8-rc1 to avoid merge conflicts. * Added CURRENT_TIME deletion and fnic patches back as time64_to_tm() is merged. * Rearranged a couple of instances of CURRENT_TIME. Changes from v2: * Fix buildbot error for uninitialized sb in inode. * Minor fixes according to Arnd's comments. * Leave out the fnic and deletion of CURRENT_TIME to be submitted after 4.8 rc1. Changes from v1: * Change current_fs_time(struct super_block *) to current_time(struct inode *) * Note that change to add time64_to_tm() is already part of John's kernel tree: https://lkml.org/lkml/2016/6/17/875 . Deepa Dinamani (5): vfs: Add current_time() api fs: proc: Delete inode time initializations in proc_alloc_inode() fs: Replace CURRENT_TIME with current_time() for inode timestamps fs: Replace CURRENT_TIME_SEC with current_time() for inode timestamps fs: Replace current_fs_time() with current_time() arch/powerpc/platforms/cell/spufs/inode.c | 2 +- arch/s390/hypfs/inode.c | 4 ++-- drivers/char/sonypi.c | 2 +- drivers/infiniband/hw/qib/qib_fs.c | 2 +- drivers/misc/ibmasm/ibmasmfs.c | 2 +- drivers/oprofile/oprofilefs.c | 2 +- drivers/platform/x86/sony-laptop.c | 2 +- drivers/usb/core/devio.c | 18 +++++++++--------- drivers/usb/gadget/function/f_fs.c | 8 ++++---- drivers/usb/gadget/legacy/inode.c | 2 +- fs/9p/vfs_inode.c | 2 +- fs/adfs/inode.c | 2 +- fs/affs/amigaffs.c | 6 +++--- fs/affs/inode.c | 2 +- fs/attr.c | 2 +- fs/autofs4/inode.c | 2 +- fs/autofs4/root.c | 6 +++--- fs/bad_inode.c | 2 +- fs/bfs/dir.c | 14 +++++++------- fs/binfmt_misc.c | 2 +- fs/btrfs/file.c | 6 +++--- fs/btrfs/inode.c | 22 +++++++++++----------- fs/btrfs/ioctl.c | 8 ++++---- fs/btrfs/transaction.c | 4 ++-- fs/btrfs/xattr.c | 2 +- fs/ceph/file.c | 4 ++-- fs/ceph/inode.c | 2 +- fs/ceph/xattr.c | 2 +- fs/cifs/file.c | 4 ++-- fs/coda/dir.c | 2 +- fs/coda/file.c | 2 +- fs/coda/inode.c | 2 +- fs/configfs/inode.c | 6 +++--- fs/debugfs/inode.c | 2 +- fs/devpts/inode.c | 6 +++--- fs/efivarfs/inode.c | 2 +- fs/exofs/dir.c | 6 +++--- fs/exofs/inode.c | 4 ++-- fs/exofs/namei.c | 6 +++--- fs/ext2/acl.c | 2 +- fs/ext2/dir.c | 6 +++--- fs/ext2/ialloc.c | 2 +- fs/ext2/inode.c | 4 ++-- fs/ext2/ioctl.c | 4 ++-- fs/ext2/namei.c | 6 +++--- fs/ext2/super.c | 2 +- fs/ext2/xattr.c | 2 +- fs/f2fs/dir.c | 8 ++++---- fs/f2fs/file.c | 8 ++++---- fs/f2fs/inline.c | 2 +- fs/f2fs/namei.c | 12 ++++++------ fs/f2fs/xattr.c | 2 +- fs/fat/dir.c | 2 +- fs/fat/file.c | 6 +++--- fs/fat/inode.c | 2 +- fs/fat/namei_msdos.c | 12 ++++++------ fs/fat/namei_vfat.c | 10 +++++----- fs/fuse/control.c | 2 +- fs/fuse/dir.c | 2 +- fs/gfs2/bmap.c | 8 ++++---- fs/gfs2/dir.c | 12 ++++++------ fs/gfs2/inode.c | 8 ++++---- fs/gfs2/quota.c | 2 +- fs/gfs2/xattr.c | 8 ++++---- fs/hfs/catalog.c | 8 ++++---- fs/hfs/dir.c | 2 +- fs/hfs/inode.c | 2 +- fs/hfsplus/catalog.c | 8 ++++---- fs/hfsplus/dir.c | 6 +++--- fs/hfsplus/inode.c | 2 +- fs/hfsplus/ioctl.c | 2 +- fs/hugetlbfs/inode.c | 10 +++++----- fs/inode.c | 29 ++++++++++++++++++++++++++--- fs/jffs2/acl.c | 2 +- fs/jffs2/fs.c | 2 +- fs/jfs/acl.c | 2 +- fs/jfs/inode.c | 2 +- fs/jfs/jfs_inode.c | 2 +- fs/jfs/namei.c | 24 ++++++++++++------------ fs/jfs/super.c | 2 +- fs/jfs/xattr.c | 2 +- fs/kernfs/inode.c | 2 +- fs/libfs.c | 14 +++++++------- fs/locks.c | 2 +- fs/logfs/dir.c | 6 +++--- fs/logfs/file.c | 2 +- fs/logfs/inode.c | 4 ++-- fs/logfs/readwrite.c | 4 ++-- fs/minix/bitmap.c | 2 +- fs/minix/dir.c | 6 +++--- fs/minix/itree_common.c | 4 ++-- fs/minix/namei.c | 4 ++-- fs/nfsd/blocklayout.c | 2 +- fs/nilfs2/dir.c | 6 +++--- fs/nilfs2/inode.c | 4 ++-- fs/nilfs2/ioctl.c | 2 +- fs/nilfs2/namei.c | 6 +++--- fs/nsfs.c | 2 +- fs/ntfs/inode.c | 2 +- fs/ntfs/mft.c | 2 +- fs/ocfs2/acl.c | 2 +- fs/ocfs2/alloc.c | 2 +- fs/ocfs2/aops.c | 2 +- fs/ocfs2/dir.c | 4 ++-- fs/ocfs2/dlmfs/dlmfs.c | 4 ++-- fs/ocfs2/file.c | 12 ++++++------ fs/ocfs2/move_extents.c | 2 +- fs/ocfs2/namei.c | 10 +++++----- fs/ocfs2/refcounttree.c | 4 ++-- fs/ocfs2/xattr.c | 2 +- fs/omfs/dir.c | 4 ++-- fs/omfs/inode.c | 2 +- fs/openpromfs/inode.c | 2 +- fs/orangefs/file.c | 2 +- fs/orangefs/inode.c | 2 +- fs/orangefs/namei.c | 10 +++++----- fs/pipe.c | 2 +- fs/posix_acl.c | 2 +- fs/proc/base.c | 2 +- fs/proc/inode.c | 3 +-- fs/proc/proc_sysctl.c | 2 +- fs/proc/self.c | 2 +- fs/proc/thread_self.c | 2 +- fs/pstore/inode.c | 2 +- fs/ramfs/inode.c | 6 +++--- fs/reiserfs/inode.c | 2 +- fs/reiserfs/ioctl.c | 4 ++-- fs/reiserfs/namei.c | 12 ++++++------ fs/reiserfs/stree.c | 8 ++++---- fs/reiserfs/super.c | 2 +- fs/reiserfs/xattr.c | 6 +++--- fs/reiserfs/xattr_acl.c | 2 +- fs/sysv/dir.c | 6 +++--- fs/sysv/ialloc.c | 2 +- fs/sysv/itree.c | 4 ++-- fs/sysv/namei.c | 4 ++-- fs/tracefs/inode.c | 2 +- fs/udf/ialloc.c | 2 +- fs/udf/inode.c | 4 ++-- fs/udf/namei.c | 20 ++++++++++---------- fs/ufs/dir.c | 6 +++--- fs/ufs/ialloc.c | 2 +- fs/ufs/inode.c | 6 +++--- fs/ufs/namei.c | 6 +++--- fs/xfs/xfs_acl.c | 2 +- fs/xfs/xfs_inode.c | 2 +- fs/xfs/xfs_iops.c | 2 +- fs/xfs/xfs_trans_inode.c | 2 +- include/linux/fs.h | 1 + ipc/mqueue.c | 18 +++++++++--------- kernel/bpf/inode.c | 2 +- mm/shmem.c | 20 ++++++++++---------- net/sunrpc/rpc_pipe.c | 2 +- security/apparmor/apparmorfs.c | 2 +- security/inode.c | 2 +- security/selinux/selinuxfs.c | 2 +- 156 files changed, 381 insertions(+), 358 deletions(-) -- 2.7.4 Cc: balbi(a)kernel.org Cc: swhiteho(a)redhat.com Cc: konishi.ryusuke(a)lab.ntt.co.jp Cc: dsterba(a)suse.com Cc: jack(a)suse.cz

8 years, 7 months

Unable to deliver your item, #000206717

by FedEx SmartPost

Dear Customer, Courier was unable to deliver the parcel to you. You can review complete details of your order in the find attached. Thank you for choosing FedEx, Dan Flowers, Sr. Station Manager.

8 years, 7 months

Unable to deliver your item, #000495582

by FedEx International Economy

Dear Customer, We could not deliver your item. Please, download Delivery Label attached to this email. Yours sincerely, Ross Helton, FedEx Station Manager.

8 years, 7 months

We could not deliver your parcel, #00000701830

by FedEx SmartPost

Dear Customer, Courier was unable to deliver the parcel to you. Delivery Label is attached to this email. Yours faithfully, Maurice Dillon, Sr. Station Manager.

8 years, 7 months

Unable to deliver your item, #00000515240

by FedEx Standard Overnight

Dear Customer, Your parcel has arrived at September 18. Courier was unable to deliver the parcel to you. Shipment Label is attached to email. Sincerely, Walter Fletcher, FedEx Station Manager.

8 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038