ld drivers that contain calls to this function.
>
> Signed-off-by: Arnd Bergmann
> ---
> include/linux/timekeeping.h | 14 --
> include/linux/timekeeping32.h | 9 -
> 2 files changed, 23 deletions(-)
Acked-by: John Stultz
___
off-by: Arnd Bergmann
> ---
> include/linux/timekeeping32.h | 6 --
> kernel/time/ntp.c | 10 +-
> kernel/time/timekeeping.c | 12 ++--
> 3 files changed, 3 insertions(+), 25 deletions(-)
Acked-by: John Stultz
thanks
-john
_
emove that as well.
>
> Signed-off-by: Arnd Bergmann
> ---
> include/linux/time32.h | 25 -
> kernel/time/time.c | 36
> 2 files changed, 61 deletions(-)
Acked-by: John Stultz
On Thu, Oct 19, 2017 at 4:14 AM, Arnd Bergmann wrote:
> This may be a somewhat controversial change, changing 64-bit architectures
> to use the same 'struct timespec64' definition that 32-bit architectures
> have, and removing a micro-optimization that tries to minimize the
> difference between ti
On Thu, Oct 19, 2017 at 4:14 AM, Arnd Bergmann wrote:
> The interfaces based on 'struct timespec' and 'unsigned long' seconds
> are no longer recommended for new code, and we are trying to migrate to
> ktime_t based interfaces and other y2038-safe variants.
>
> This moves all the legacy interfaces
On Thu, Jun 1, 2017 at 5:26 PM, Yan, Zheng wrote:
> On Thu, Jun 1, 2017 at 6:22 PM, Arnd Bergmann wrote:
>> On Thu, Jun 1, 2017 at 11:56 AM, Yan, Zheng wrote:
>>> On Sat, Apr 8, 2017 at 8:57 AM, Deepa Dinamani
>>> wrote:
>>
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index
viewed-by: Arnd Bergmann
> Cc: John Stultz
> Cc: Thomas Gleixner
Assuming all the users are gone when this is applied:
Acked-by: John Stultz
thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
On Wed, Jun 22, 2016 at 10:26 AM, Stephan Mueller wrote:
> Hi John, Herbert,
>
> Changes v2: use ktime_get_ns instead of ktime_get_raw_ns
>
> The testing was re-performed and indicate no difference to the previous
> testing.
Thanks for following through on this. This version addresses my
concern
On Tue, Jun 21, 2016 at 12:37 PM, Arnd Bergmann wrote:
> On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote:
>> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller
>> wrote:
>> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
>> >
>> &
On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
>
> Hi John,
>
>> I don't see in the above an explanation of *why* you're using
>> ktime_get_raw_ns() instead of ktime_get_ns().
>
&g
On Tue, Jun 21, 2016 at 11:05 AM, Stephan Mueller wrote:
> As part of the Y2038 development, __getnstimeofday is not supposed to be
> used any more. It is now replaced with ktime_get_raw_ns. Albeit
> ktime_get_raw_ns is monotonic compared to __getnstimeofday, this
> difference is irrelevant as the
On Tue, Jun 21, 2016 at 9:51 AM, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller
> wrote:
>> > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>> &g
On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
>
> Hi John,
>
>> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote:
>> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> &g
On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote:
> On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>>
> Compared to the previous __getnstimeofday(), the difference is
>
> - using "monotonic" timebase instead of "re
On Wed, Jun 15, 2016 at 10:44 AM, Deepa Dinamani wrote:
> On Tue, Jun 14, 2016 at 2:18 PM, John Stultz wrote:
>> On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani
>> wrote:
>>> time_to_tm() takes time_t as an argument.
>>> time_t is not y2038 safe.
>>>
On Fri, Jun 17, 2016 at 9:03 AM, Arnd Bergmann wrote:
> udelay_test_single() uses ktime_get_ts() to get two timespec values
> and calculate the difference between them, while udelay_test_show()
> uses the same to printk() the current monotonic time.
>
> Both of these are y2038 safe on all machines
On Fri, Jun 17, 2016 at 8:30 AM, Arnd Bergmann wrote:
> The tstats_show() function prints a ktime_t variable by converting
> it to struct timespec first. The algorithm is ok, but we want to
> stop using timespec in general because of the 32-bit time_t
> overflow problem.
>
> This changes the code
n place:
Acked-by: John Stultz
thanks
-john
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
t; by time64_to_tm().
>
> Signed-off-by: Deepa Dinamani
> Cc: John Stultz
> Cc: Thomas Gleixner
This looks sane to me. Are you hoping for me to queue this, or would
you like i to go though the fsdev maintainers with my ack?
In either case.
Acked-
ike a straightforward
> substitution in areas which will get plenty of testing
Yea. My main concern is just not stepping on any other maintainers toes.
> I'll grab the patches for now to get them some external testing.
I'd be just as happy if the set went through you And
On Wed, May 4, 2016 at 12:24 PM, Deepa Dinamani wrote:
> struct timespec is not y2038 safe.
> Even though timespec might be sufficient to represent
> timeouts, use struct timespec64 here as the plan is to
> get rid of all timespec reference in the kernel.
>
> The patch transitions the common funct
cessary as part of y2038 changes.
> struct timespec is not y2038 safe. All references to timespec will
> be replaced by struct timespec64. The function is meant to be a
> replacement for timespec_add_safe().
>
> The implementation is similar to timespec_add_safe().
>
> Signed-of
the ptp subsystem), so
>> > I have to convert that driver at the same time.
>> >
>> > The patches should ideally stay together as a series, but they do
>> > span multiple subsystems, so I'm also looking for the right person
>> > to merge them.
>
On Mon, Jun 29, 2015 at 7:23 AM, Bamvor Zhang Jian
wrote:
> Add compat ioctl in ppdev in order to solve the y2038 issue in
> later patch.
> This patch simply add pp_do_ioctl to compat_ioctl, because I found
> that all the ioctl access the arg as a pointer.
>
> Signed-off-by: Bamvor Zhang Jian
> -
On Mon, Jun 22, 2015 at 9:31 AM, Ksenija Stanojevic
wrote:
> @@ -1175,7 +1175,7 @@ static long rxrpc_read(const struct key *key,
> ENCODE(token->kad->kvno);
> ENCODE_DATA(8, token->kad->session_key);
> ENCODE(token->kad->start
On Fri, May 29, 2015 at 5:16 AM, Baolin Wang wrote:
> This patch series changes the 32-bit time types (timespec/itimerspec) to
> the 64-bit types (timespec64/itimerspec64), since 32-bit time types will
> break in the year 2038.
>
> This patch series introduces new methods with timespec64/itimerspe
On Tue, May 19, 2015 at 5:49 AM, Baolin Wang wrote:
> This patch introduces the clock_set64 method with timespec64 type for
> k_clock structure, that makes it ready for the 2038 year.
>
> Convert to the 64bit method with timespec64 type for the
> clock_settime syscall function, and change the cloc
On Mon, May 18, 2015 at 2:53 AM, Arnd Bergmann wrote:
> In the patch series I posted recently [1], I introduce new system calls to
> deal
> with modified data structures, but left the question open on how these should
> be best accessed from libc. The patches introduce a new __kernel_time64_t typ
On Wed, May 13, 2015 at 2:10 PM, Mauro Carvalho Chehab
wrote:
> Em Wed, 13 May 2015 21:53:07 +0200
> Arnd Bergmann escreveu:
>
>> On Wednesday 13 May 2015 10:04:48 John Stultz wrote:
>> > On Wed, May 13, 2015 at 9:57 AM, Ksenija Stanojevic
>> > wrote:
>>
On Wed, May 13, 2015 at 9:57 AM, Ksenija Stanojevic
wrote:
> 'struct timeval last_tv' is used to get the time of last signal change
> and 'struct timeval last_intr_tv' is used to get the time of last UART
> interrupt.
> 32-bit systems using 'struct timeval' will break in the year 2038, so we
> hav
On Sun, May 10, 2015 at 9:38 AM, Ksenija Stanojevic
wrote:
> 'struct timeval last_tv' is used to get the time of last signal change
> and 'struct timeval last_intr_tv' is used to get the time of last UART
> interrupt.
> 32-bit systems using 'struct timeval' will break in the year 2038, so we
> hav
31 matches
Mail list logo
