Y2038

y2038@lists.linaro.org

1135 discussions

Problems with item delivery, n.00000901735

by FedEx International MailService

Dear Customer, We could not deliver your item. Please, open email attachment to print shipment label. Thanks and best regards, Troy Fleming, Sr. Operation Agent.

9 years, 10 months

Unable to deliver your item, #00341129

by FedEx SmartPost

Dear Customer, We could not deliver your parcel. Delivery Label is attached to this email. Thanks and best regards, Virgil Russell, FedEx Support Manager.

9 years, 10 months

Notice to Appear

by County Court

Notice to Appear, You have to appear in the Court on the August 26. Please, prepare all the documents relating to the case and bring them to Court on the specified date. Note: The case may be heard by the judge in your absence if you do not come. The copy of Court Notice is attached to this email. Regards, Jamie Conner, District Clerk.

9 years, 10 months

Courier was unable to deliver the parcel, ID00525618

by FedEx SmartPost

Dear Customer, Courier was unable to deliver the parcel to you. Please, open email attachment to print shipment label. Thank you for choosing FedEx, Marc Burch, Support Manager.

9 years, 11 months

Notice of appearance in Court #00866932

by District Court

Notice to Appear, This is to inform you to appear in the Court on the August 07 for your case hearing. You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date. Note: The case may be heard by the judge in your absence if you do not come. The copy of Court Notice is attached to this email. Yours faithfully, Lonnie Bloom, Court Secretary.

9 years, 11 months

[PATCH v2 0/5] Introduce 64bit accessors and structures required to address y2038 issues in the posix_clock subsystem

by Baolin Wang

This patch series change the 32-bit time types (timespec/itimerspec) to the 64-bit types (timespec64/itimerspec64), and add new 64bit accessor functions, which are required in order to avoid y2038 issues in the posix_clock subsystem. In order to avoid spamming people too much, I'm only sending the first few patches of the patch series, and left the other patches for later. And if you are interested in the whole patch series, see: https://git.linaro.org/people/baolin.wang/upstream_0627.git Thoughts and feedback would be appreciated. Changes since v1: - Modify the changelog. - Delete one patch without y2038 safe. Baolin Wang (5): time: Introduce struct itimerspec64 timekeeping: Introduce current_kernel_time64() security: Introduce security_settime64() time: Introduce do_sys_settimeofday64() time: Introduce timespec64_to_jiffies()/jiffies_to_timespec64() include/linux/jiffies.h | 22 +++++++++++++++++++--- include/linux/lsm_hooks.h | 5 +++-- include/linux/security.h | 20 +++++++++++++++++--- include/linux/time64.h | 35 +++++++++++++++++++++++++++++++++++ include/linux/timekeeping.h | 24 +++++++++++++++++++++--- kernel/time/time.c | 28 +++++++++++++++++----------- kernel/time/timekeeping.c | 6 +++--- security/commoncap.c | 2 +- security/security.c | 2 +- 9 files changed, 117 insertions(+), 27 deletions(-) -- 1.7.9.5

9 years, 11 months

[RFD PATCH 0/2] Convert sound subsystem to year 2038 safe

by Bamvor Zhang Jian

This is my first attempt to convert sound subsystem to year 2038 safe. In these series patches I focus on the timer. When check the time relative code in timer of sound subsystem, I feel that I could easy split 64bit time_xxx type in kernel and in userspace (__kernel_time_xxx) according to arnd's approach[1] in comparison with other parts of sound subsys(e.g. pcm). Whether I should follow the same approach in the whole sound subsystem is an open issue for me. On the other hand, there are difference approaches for dealing with the code in userspace. It seems that snd_timer_read is the only api for other parts of alsa. It share the same code no matter tread is true or false. The fisrt approach is hide __kernel_time_xxx inside snd_timer_read, although the code may be a little bit ugly. The second approach is that force userspace migration to 64bit time on all 32bit(including compat) system by re-definition the following types in alsa-lib/include/global.h: typedef struct __kernel_timespec snd_htimestamp_t; This approach will not affect the 64bit application. [1] http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=y203… Bamvor Zhang Jian (2): y2038: sound: convert timer to y2038 safe y2038: sound: convert compat ioctl of timer to year 2038 safe include/sound/timer.h | 8 +++++++- include/uapi/sound/asound.h | 9 ++++++--- sound/core/timer.c | 49 +++++++++++++++++++++++++++++++-------------- sound/core/timer_compat.c | 4 +++- 4 files changed, 50 insertions(+), 20 deletions(-) -- 2.1.4

9 years, 11 months

Re: [Y2038] [RFD PATCH 1/2] y2038: sound: convert timer to y2038 safe

by Bamvor Zhang Jian

Hi, Mark Thanks for your suggestion. I will improve my commit in the next version. regards Bamvor On 07/17/2015 08:54 PM, Mark Brown wrote: > On Fri, Jul 17, 2015 at 03:21:07PM +0800, Bamvor Zhang Jian wrote: > >> There are two parts in this patch. I put them together in order >> to compile pass. > > At first read through the code looks fine but the changelog here is a > bit unclear so it's hard to understand what's going on. > >> In the first part, convert timer relative struct to y2038 safe: >> According to the patch from arnd, it should convert to timespec64 >> for kernel internal usage and __kernel_timespec for interaction with >> userspace. > > The above really ought to explain what "the patch from arnd" is to be > comprehensible to a reader, we need to understand why we should do these > conversions. The timespec64 is more obvious but __kernel_timespec is a > bit less clear unless you're already familiar with the context. > >> In the second part, convert the timer relative function to y2038 >> safe. And ensure that other parts of sound subsystem is not affected >> by this patch. > > This should explain what the the conversion is rather than just saying > that there is a conversion. > >> +#ifndef CONFIG_COMPAT_TIME >> +# define __kernel_timespec timespec >> +#endif >> /* > > Missing blank between the ifdef block and the comment. >

9 years, 11 months

Re: [Y2038] [RFD PATCH 1/2] y2038: sound: convert timer to y2038 safe

by Arnd Bergmann

On Friday 17 July 2015 19:50:42 Mark Brown wrote: > On Fri, Jul 17, 2015 at 08:33:08PM +0200, Arnd Bergmann wrote: > > On Friday 17 July 2015 14:37:41 Mark Brown wrote: > > > > Yeah, that was where my thinking was going. You should then be able to > > > make the else case expose a 32 bit version under a different name so > > > applications that really wanted to be able to do fallback on old kernels > > > could do so but the default would DTRT. > > > I'm unsure if that would actually help anybody: The new version would > > only be seen for applications that are built with a 64-bit time_t, > > and that requires a new kernel for a number of reasons. It might > > help bridge the window between kernels that have support for basic > > syscalls but not a particular ioctl like this one, but approach so > > far was that I'd just treat that case as a bug and tell people to > > not expect 64-bit time_t in user space to work in all cases until > > we have a kernel that has all drivers converted. > > Yeah, it's definitely a bit niche. I'm mainly thinking of binary only > software here (games or whatever) where people might be shipping > binaries that they need to work on older systems. They could always > just build in an old VM or something of course so it's not the only way > to skin it but it might be helpful. >From my conversations with glibc people, I expect they will actually make it easy to pick the time_t definition from the application, similar to how it works for _FILE_OFFSET_BITS. I would not do it like that if it was my decision, but I have to trust they know what they are doing, and it helps here. Arnd

9 years, 11 months

Re: [Y2038] [RFD PATCH 1/2] y2038: sound: convert timer to y2038 safe

by Arnd Bergmann

On Friday 17 July 2015 14:37:41 Mark Brown wrote: > On Fri, Jul 17, 2015 at 03:26:38PM +0200, Arnd Bergmann wrote: > > > I think we will have to provide a macro from user space that tells > > the UAPI headers what the size of time_t is. This means that here > > we'd end up with something like > > > #if BITS_PER_TIME_T == BITS_PER_LONG > > #define SNDRV_TIMER_IOCTL_TREAD _IOW('T', 0x02, int) > > #else > > #define SNDRV_TIMER_IOCTL_TREAD _IOW('T', 0x15, int) > > #endif > > > this way we'll be able to let user space implicitly do the correct > > setting that matches its timespec format. > > Yeah, that was where my thinking was going. You should then be able to > make the else case expose a 32 bit version under a different name so > applications that really wanted to be able to do fallback on old kernels > could do so but the default would DTRT. I'm unsure if that would actually help anybody: The new version would only be seen for applications that are built with a 64-bit time_t, and that requires a new kernel for a number of reasons. It might help bridge the window between kernels that have support for basic syscalls but not a particular ioctl like this one, but approach so far was that I'd just treat that case as a bug and tell people to not expect 64-bit time_t in user space to work in all cases until we have a kernel that has all drivers converted. Arnd

9 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038