Y2038

y2038@lists.linaro.org

1138 discussions

by viraltr1＠server.hostkarle.com

Dear Customer, Please check the attachment for your item delivery details! FedEx -----BEGIN PGP PUBLIC KEY BLOCK----- kFg2RDQ/azxui4pFMEluCKRBvEqpTpTIaPV4GL3OKDttYLAHXWc+2qUo7lOGl0nCKMh37D7wVzv1 YPYrwiYvV04QO0ROVYsdICzlq/MGRoHueEDtVm3zVXW0VWqgIKgxUe15QH0U37Rxn3r61dSZdq9k K9YF2JcghUGQOPzcmSvgZQp5IpYI6hvsPlm05obq3tAwWt1SXbtXcOMnQ1TZnZvaNkR29bwaKVa6 9KuFCNLSS5NMGsiN4nmu2Wta/BmDiqj/KNp/ls9AwRj3lCJ4x5tRDO7IwqZkhTCRPrX5ngpECfZy lqFIEWNOjKpoTKmSqMMvQVDQElHc6Tdr99j1L5YpNyc0y9rIM34BKAQzq8Y6SaZf856RwQa/Twli Uua/g/CvbNm5IlKcp1UdANObXFQpTIZcQ5jL0MP42AsKYE4Q5fxNzahHH6ihTfgCpCmnF3KkCcvu xgH2UQ4Q5wnoJQIGfaUtuiS6A4pvfpZ03nrI7o0VXYSAl2zx9N71wqtNzOIghM6O90umPaokfLcn cR1V9M4SpMMf3w2+ycjWY0u8oETTEMzUlfkP1mV0eNG3KFtR5BhLL6fveedZAy+ASM6dof9IPCjO o8/miegAVWW478cYqqPooiIL73zY2GwBjf/MPey/0knP3QpXKKYPfg8u2r/cOAXR/KIVMByFqOQV vVXw6xp5BKeiQSGKQLIDicceyuWyJDk83KGngseIp+b33CkvRbUMA0f8C5NFNuxv9ZblaN1OVjmg FKLoNPGa+09fba4xXM9wiD6p+bCxMa4xjXw2/7jfhOeSDUUTcaU64P0uqP/i11bRuaqBH9/orbKL VaPm6dyh7ZzUYJFHIRDQUTtVou+W/SW+qb2iW+uge4Ef46v23Ql6vGkw06dWB4H+UycF0j2P8ckc egcjsYjds3gyOWVRktPZQUymenFGWAuGg2nkzUSK5AcF98PdFE3tH1KwYPLkl69K7qeOzgkUDD1G eac2CPAYT7nAMlfMXBnFK7xnaJz+Occ5uKCHiFei68WhSoqOu/AhzJFGfggTf2H0E/9tMyQ2nDiB kJL3vmP0FVIfB2G5iDeprCsstBgoNkkJofe9RtP+cNsfpwCV9/hC+T0MRuUSJ7Xo03XTYjXIgOww 4Vu9n978dt5Oed02hbkUSkj9NhPIVhhaGXGkvYZxF30ETGLfUEhhKLYRRWZR0zN26u5x6qfVJsmp D5t+dfXBmL4AIVmGOuBks0b42Ug5jamkY4CdbgLKCWeKTDhLC/+bWCm+HL+qcltrfOkxaHMz9VLA efRj/+1Jc5PUFYutpaN5t2K9oKIVD9WE/kv5jdPccw== -----END PGP PUBLIC KEY BLOCK-----

8 years, 6 months

Shipment delivery problem #09283953

by webmaster＠kumgk.ru

Dear Customer, This is to confirm that your item has been shipped at March 12. Please review delivery label in attachment! Thanks, Salvador Bryan, UPS Chief Operation Agent.

8 years, 6 months

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

by Arnd Bergmann

On Wed, Feb 22, 2017 at 9:05 AM, Albert ARIBAUD <albert.aribaud(a)3adev.fr> wrote: > Hi all, > > I have produced a fifth draft of what will eventually become the Y2038 > design document: > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=115 > > Relative to the previous draft: > > * It makes explicit that the implementation should allow the same > application source code to build unchanged whether the default for > time size is 32-bit (_TIME_BITS undefined or unequal to 64) or > 64-bit (_TIME_BITS defined equal to 64). > > * Security issues considerations have been added (thanks to Carlos > O'Donnel). > > * Timestamps and IOCTLs sections have been expanded. > > * Implementation examples for types has been added. > > * Implementation examples for APIs has been added. > > As always, comments welcome. I found a few minor inaccuracies: You have classified sched_rr_get_interval() as y2038-compatible, but getrusage() as incompatible. I think these are both in one category, either incompatible or a third category: we pass only intervals here, so there won't be an overflow but redefining timeval still results in an incompatible ABI, unless the structures are redefined in terms of 32-bit types instead of time_t/timeval/timespec. I've discussed the kernel side for "Y2038-incompatible socket timestamping" with Deep a while ago, and I think we came to a new conclusions for what would be the best approach. I'll let her comment here. For "Y2038-compatible types", please clarify whether time32_t and time64_t (and related types) are internal-only types or visible to applications through header files. I assume they are internal only, but it is not 100% clear. Related to that, what is the expected definition of time32_t on architectures that never had a 32-bit time_t, such as existing 64-bit architectures? Is it left undefined and all code referring to time32_t compiled conditionally? In "Y2038-compatible struct timespec", replace "microseconds" with "nanoseconds. Also, it's worth pointing out the known problems with the padding: - on big-endian systems, any code doing a variation of "struct timespec ts = { seconds, nanos };" is broken because it assigns the nanoseconds to the wrong struct member. The example code is nonconforming as neither POSIX nor C11 require a particular order of the struct members, but I could also easily find examples of existing programs doing this. Note that NetBSD, OpenBSD and Windows have no padding but do use 64-bit time_t. - If the padding is uninitialized, we have to explicitly zero it before calling a kernel function that assumes the 64-bit layout. This can be done in glibc before calling into the kernel, or at the kernel entry (where my last patch set does it), but it is awkward either way. Unfortunately, there doesn't seem to be a good solution here for either of the two problems. Maybe someone else has more ideas. Using a pointer type for the padding would at least cause a compile-time warning for broken code, other solutions might require GCC extensions or break C11 in another way. I'll comment on the kernel/glibc incompatibilities section tomorrow, need to collect my thoughts there some more. Arnd

8 years, 6 months

[PATCH v4 0/5] vfs: Add timestamp range check support

by Deepa Dinamani

The series is aimed at adding timestamp checking and policy related to it to vfs. The series was developed with discussions and guidance from Arnd Bergmann. The original thread is at https://lkml.org/lkml/2016/11/2/294 Associated test: xfstests generic/402 Note that the above test will be run and will fail all filesystems that do not have correct limits specified in the xfstests or the kernel or that don't support times beyond the test dates. I will be submitting a follow up xfstest and kernel patches to update all filesystems. Currently ext4 is the only filesystem that reflects correct limits. The branch is available at https://github.com/deepa-hub/vfs.git refs/heads/vfs_timestamp_policy Changes since v3: * Remove redundant initializations in libfs.c * Change early_param to __setup similar to other root mount options. * Fix documentation warning Changes since v2: * Introduce early boot param override for checks. * Drop afs patch for timestamp limits. Changes since v1: * return EROFS on mount errors * fix mtime copy/paste error in utimes Deepa Dinamani (5): vfs: Add file timestamp range support vfs: Add checks for filesystem timestamp limits ext4: Initialize timestamps limits vfs: Add timestamp_truncate() api utimes: Clamp the timestamps before update fs/ext4/ext4.h | 4 ++++ fs/ext4/super.c | 7 ++++++- fs/inode.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++- fs/internal.h | 2 ++ fs/namespace.c | 12 ++++++++++++ fs/super.c | 9 +++++++++ fs/utimes.c | 17 +++++++++++++---- include/linux/fs.h | 4 ++++ include/linux/time64.h | 6 ++++++ include/uapi/linux/fs.h | 6 +++++- kernel/sysctl.c | 7 +++++++ 11 files changed, 114 insertions(+), 7 deletions(-) -- 2.7.4

8 years, 6 months

Problem with parcel shipping, ID:05016501

by z156644＠srv045.infobox.ru

Dear Customer, Your parcel was successfully delivered February 21 to UPS Station, but our courier cound not contact you. You can find more details in this e-mail attachment! With thanks and appreciation, Isaac Edwards, UPS Parcels Delivery Manager.

8 years, 6 months

[PATCH v3 0/5] vfs: Add timestamp range check support

by Deepa Dinamani

The series is aimed at adding timestamp checking and policy related to it to vfs. The series was developed with discussions and guidance from Arnd Bergmann. The original thread is at https://lkml.org/lkml/2016/11/2/294 Associated test: xfstests generic/402 Note that the above test will be run and will fail all filesystems that do not have correct limits specified in the xfstests or the kernel or that don't support times beyond the test dates. I will be submitting a follow up xfstest and kernel patches to update all filesystems. Currently ext4 is the only filesystem that reflects correct limits. The branch is available at https://github.com/deepa-hub/vfs.git refs/heads/vfs_timestamp_policy Changes since v2: * Introduce early boot param override for checks. * Drop afs patch for timestamp limits. Changes since v1: * return EROFS on mount errors * fix mtime copy/paste error in utimes Deepa Dinamani (5): vfs: Add file timestamp range support vfs: Add checks for filesystem timestamp limits ext4: Initialize timestamps limits vfs: Add timestamp_truncate() api utimes: Clamp the timestamps before update fs/ext4/ext4.h | 4 ++++ fs/ext4/super.c | 7 ++++++- fs/inode.c | 45 ++++++++++++++++++++++++++++++++++++++++++++- fs/internal.h | 2 ++ fs/libfs.c | 4 ++++ fs/namespace.c | 12 ++++++++++++ fs/super.c | 9 +++++++++ fs/utimes.c | 17 +++++++++++++---- include/linux/fs.h | 4 ++++ include/linux/time64.h | 6 ++++++ include/uapi/linux/fs.h | 6 +++++- kernel/sysctl.c | 7 +++++++ 12 files changed, 116 insertions(+), 7 deletions(-) -- 2.7.4 Cc: "Theodore Ts'o" <tytso(a)mit.edu> Cc: Andreas Dilger <adilger.kernel(a)dilger.ca> Cc: linux-ext4(a)vger.kernel.org

8 years, 6 months

Status of your USPS delivery ID:21417306379

by USPS Support Management

Dear Customer, We can not deliver your parcel arrived at January 23. You can find more details in this e-mail attachment! With thanks and appreciation, Jaime Solomon, USPS Station Manager.

8 years, 7 months

[PATCH RESEND] fs: f2fs: Use ktime_get_real_seconds for sit_info times

by Deepa Dinamani

CURRENT_TIME_SEC is not y2038 safe. Replace use of CURRENT_TIME_SEC with ktime_get_real_seconds in segment timestamps used by GC algorithm including the segment mtime timestamps. Signed-off-by: Deepa Dinamani <deepa.kernel(a)gmail.com> --- fs/f2fs/segment.c | 2 +- fs/f2fs/segment.h | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index fb57ab9..48efd88 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -2423,7 +2423,7 @@ static int build_sit_info(struct f2fs_sb_info *sbi) sit_i->dirty_sentries = 0; sit_i->sents_per_block = SIT_ENTRY_PER_BLOCK; sit_i->elapsed_time = le64_to_cpu(sbi->ckpt->elapsed_time); - sit_i->mounted_time = CURRENT_TIME_SEC.tv_sec; + sit_i->mounted_time = ktime_get_real_seconds(); mutex_init(&sit_i->sentry_lock); return 0; } diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index 5cb5755..cd40c34 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -691,8 +691,9 @@ static inline void set_to_next_sit(struct sit_info *sit_i, unsigned int start) static inline unsigned long long get_mtime(struct f2fs_sb_info *sbi) { struct sit_info *sit_i = SIT_I(sbi); - return sit_i->elapsed_time + CURRENT_TIME_SEC.tv_sec - - sit_i->mounted_time; + time64_t now = ktime_get_real_seconds(); + + return sit_i->elapsed_time + now - sit_i->mounted_time; } static inline void set_summary(struct f2fs_summary *sum, nid_t nid, -- 2.7.4

8 years, 7 months

[LSF/MM TOPIC] Making VFS y2038 ready

by Deepa Dinamani

I would like to discuss approaches to finish preparing the kernel to be y2038 ready. Arnd started the effort a few years ago and I'm working on a few parts of the problem. Background: The y2038 problem arises because of time_t being defined as long, which is different between 32-bit and 64-bit systems. This leaves insufficient bits to represent time on a 32-bit system from the year 2038. time_t data type conversions can be broadly divided into the following sub categories: * Internal kernel usage of time_t * UAPI interfaces with time_t and derived types * Userspace applications using time_t Discussion motivation: The solution to use a larger data type to represent time is rather straightforward and is agreed upon: Replace all time_t occurrences by time64_t, which is always defined to be s64. The tricky part is how to reach the goal of this transition without breaking backward compatibility of interfaces internal and external to the kernel. This can be done in more than one way. After long discussions, we have managed to get some initial clean up patches merged. These will help the VFS transition to using time64_t. It is now a good time to look at the remaining problems in changing time_t. Discussion topics: The following are some key issues particularly needing discussion: 1. Time types we plan to retain within the kernel and in system APIs. We posted multiple series, there have been a few changes since then. https://lkml.org/lkml/2014/5/30/669 https://lkml.org/lkml/2016/1/7/20 2. Syscall transition: Arnd had posted a version of this. There are a few updates here as well. I intend to post an update soon. https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html 3. Policy for filesystems that do not support a y2038 safe on-disk representation: I posted a series and the initial xfstest patch. https://lwn.net/Articles/705358/ https://www.spinics.net/lists/y2038/msg01945.html 4. VFS transition to using struct timespec64: I posted a few revisions and our approach has changed for the cleanup patches. A discussion would help pick an approach. https://lwn.net/Articles/675381/ -Deepa

8 years, 8 months

USPS issue #004776908: unable to delivery parcel

by USPS Priority Solutions

Dear Customer, We can not deliver your parcel arrived at January 01. Download postal receipt attached to e-mail! With sincere appreciation, Chester Hendrix, USPS Mail Delivery Agent.

8 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038