2019-05-27 06:55:01 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2007-06-25 23:50:32 +00:00
|
|
|
/*
|
2005-11-11 10:15:21 +00:00
|
|
|
* Userland implementation of gettimeofday() for 64 bits processes in a
|
|
|
|
|
* ppc64 kernel for use in the vDSO
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2004 Benjamin Herrenschmuidt (benh@kernel.crashing.org),
|
|
|
|
|
* IBM Corp.
|
|
|
|
|
*/
|
|
|
|
|
#include <asm/processor.h>
|
|
|
|
|
#include <asm/ppc_asm.h>
|
|
|
|
|
#include <asm/vdso.h>
|
|
|
|
|
#include <asm/asm-offsets.h>
|
|
|
|
|
#include <asm/unistd.h>
|
|
|
|
|
|
|
|
|
|
.text
|
|
|
|
|
/*
|
|
|
|
|
* Exact prototype of gettimeofday
|
|
|
|
|
*
|
|
|
|
|
* int __kernel_gettimeofday(struct timeval *tv, struct timezone *tz);
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
V_FUNCTION_BEGIN(__kernel_gettimeofday)
|
|
|
|
|
.cfi_startproc
|
|
|
|
|
mflr r12
|
|
|
|
|
.cfi_register lr,r12
|
|
|
|
|
|
|
|
|
|
mr r11,r3 /* r11 holds tv */
|
|
|
|
|
mr r10,r4 /* r10 holds tz */
|
|
|
|
|
bl V_LOCAL_FUNC(__get_datapage) /* get data page */
|
2007-06-29 20:49:50 +00:00
|
|
|
cmpldi r11,0 /* check if tv is NULL */
|
2007-06-25 23:50:32 +00:00
|
|
|
beq 2f
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
lis r7,1000000@ha /* load up USEC_PER_SEC */
|
|
|
|
|
addi r7,r7,1000000@l
|
|
|
|
|
bl V_LOCAL_FUNC(__do_get_tspec) /* get sec/us from tb & kernel */
|
|
|
|
|
std r4,TVAL64_TV_SEC(r11) /* store sec in tv */
|
|
|
|
|
std r5,TVAL64_TV_USEC(r11) /* store usec in tv */
|
2007-06-25 23:50:32 +00:00
|
|
|
2: cmpldi r10,0 /* check if tz is NULL */
|
2005-11-11 10:15:21 +00:00
|
|
|
beq 1f
|
|
|
|
|
lwz r4,CFG_TZ_MINUTEWEST(r3)/* fill tz */
|
|
|
|
|
lwz r5,CFG_TZ_DSTTIME(r3)
|
|
|
|
|
stw r4,TZONE_TZ_MINWEST(r10)
|
|
|
|
|
stw r5,TZONE_TZ_DSTTIME(r10)
|
|
|
|
|
1: mtlr r12
|
2005-11-16 02:54:32 +00:00
|
|
|
crclr cr0*4+so
|
2005-11-11 10:15:21 +00:00
|
|
|
li r3,0 /* always success */
|
|
|
|
|
blr
|
|
|
|
|
.cfi_endproc
|
|
|
|
|
V_FUNCTION_END(__kernel_gettimeofday)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Exact prototype of clock_gettime()
|
|
|
|
|
*
|
|
|
|
|
* int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp);
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
V_FUNCTION_BEGIN(__kernel_clock_gettime)
|
|
|
|
|
.cfi_startproc
|
|
|
|
|
/* Check for supported clock IDs */
|
|
|
|
|
cmpwi cr0,r3,CLOCK_REALTIME
|
|
|
|
|
cmpwi cr1,r3,CLOCK_MONOTONIC
|
2005-11-14 03:55:58 +00:00
|
|
|
cror cr0*4+eq,cr0*4+eq,cr1*4+eq
|
2017-10-16 05:49:14 +00:00
|
|
|
|
|
|
|
|
cmpwi cr5,r3,CLOCK_REALTIME_COARSE
|
|
|
|
|
cmpwi cr6,r3,CLOCK_MONOTONIC_COARSE
|
|
|
|
|
cror cr5*4+eq,cr5*4+eq,cr6*4+eq
|
|
|
|
|
|
|
|
|
|
cror cr0*4+eq,cr0*4+eq,cr5*4+eq
|
2005-11-11 10:15:21 +00:00
|
|
|
bne cr0,99f
|
|
|
|
|
|
|
|
|
|
mflr r12 /* r12 saves lr */
|
|
|
|
|
.cfi_register lr,r12
|
|
|
|
|
mr r11,r4 /* r11 saves tp */
|
|
|
|
|
bl V_LOCAL_FUNC(__get_datapage) /* get data page */
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
lis r7,NSEC_PER_SEC@h /* want nanoseconds */
|
|
|
|
|
ori r7,r7,NSEC_PER_SEC@l
|
2017-10-16 05:49:14 +00:00
|
|
|
beq cr5,70f
|
2008-10-27 23:56:03 +00:00
|
|
|
50: bl V_LOCAL_FUNC(__do_get_tspec) /* get time from tb & kernel */
|
|
|
|
|
bne cr1,80f /* if not monotonic, all done */
|
2005-11-11 10:15:21 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* CLOCK_MONOTONIC
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* now we must fixup using wall to monotonic. We need to snapshot
|
|
|
|
|
* that value and do the counter trick again. Fortunately, we still
|
2008-10-27 23:56:03 +00:00
|
|
|
* have the counter value in r8 that was returned by __do_get_tspec.
|
|
|
|
|
* At this point, r4,r5 contain our sec/nsec values.
|
2005-11-11 10:15:21 +00:00
|
|
|
*/
|
|
|
|
|
|
powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038
Jakub Drnec reported:
Setting the realtime clock can sometimes make the monotonic clock go
back by over a hundred years. Decreasing the realtime clock across
the y2k38 threshold is one reliable way to reproduce. Allegedly this
can also happen just by running ntpd, I have not managed to
reproduce that other than booting with rtc at >2038 and then running
ntp. When this happens, anything with timers (e.g. openjdk) breaks
rather badly.
And included a test case (slightly edited for brevity):
#define _POSIX_C_SOURCE 199309L
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>
long get_time(void) {
struct timespec tp;
clock_gettime(CLOCK_MONOTONIC, &tp);
return tp.tv_sec + tp.tv_nsec / 1000000000;
}
int main(void) {
long last = get_time();
while(1) {
long now = get_time();
if (now < last) {
printf("clock went backwards by %ld seconds!\n", last - now);
}
last = now;
sleep(1);
}
return 0;
}
Which when run concurrently with:
# date -s 2040-1-1
# date -s 2037-1-1
Will detect the clock going backward.
The root cause is that wtom_clock_sec in struct vdso_data is only a
32-bit signed value, even though we set its value to be equal to
tk->wall_to_monotonic.tv_sec which is 64-bits.
Because the monotonic clock starts at zero when the system boots the
wall_to_montonic.tv_sec offset is negative for current and future
dates. Currently on a freshly booted system the offset will be in the
vicinity of negative 1.5 billion seconds.
However if the wall clock is set past the Y2038 boundary, the offset
from wall to monotonic becomes less than negative 2^31, and no longer
fits in 32-bits. When that value is assigned to wtom_clock_sec it is
truncated and becomes positive, causing the VDSO assembly code to
calculate CLOCK_MONOTONIC incorrectly.
That causes CLOCK_MONOTONIC to jump ahead by ~4 billion seconds which
it is not meant to do. Worse, if the time is then set back before the
Y2038 boundary CLOCK_MONOTONIC will jump backward.
We can fix it simply by storing the full 64-bit offset in the
vdso_data, and using that in the VDSO assembly code. We also shuffle
some of the fields in vdso_data to avoid creating a hole.
The original commit that added the CLOCK_MONOTONIC support to the VDSO
did actually use a 64-bit value for wtom_clock_sec, see commit
a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to
32 bits kernel") (Nov 2005). However just 3 days later it was
converted to 32-bits in commit 0c37ec2aa88b ("[PATCH] powerpc: vdso
fixes (take #2)"), and the bug has existed since then AFAICS.
Fixes: 0c37ec2aa88b ("[PATCH] powerpc: vdso fixes (take #2)")
Cc: stable@vger.kernel.org # v2.6.15+
Link: http://lkml.kernel.org/r/HaC.ZfES.62bwlnvAvMP.1STMMj@seznam.cz
Reported-by: Jakub Drnec <jaydee@email.cz>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-03-13 13:14:38 +00:00
|
|
|
ld r6,WTOM_CLOCK_SEC(r3)
|
2008-10-27 23:56:03 +00:00
|
|
|
lwa r9,WTOM_CLOCK_NSEC(r3)
|
2005-11-11 10:15:21 +00:00
|
|
|
|
2008-10-27 23:56:03 +00:00
|
|
|
/* We now have our result in r6,r9. We create a fake dependency
|
2005-11-11 10:15:21 +00:00
|
|
|
* on that result and re-check the counter
|
|
|
|
|
*/
|
2008-10-27 23:56:03 +00:00
|
|
|
or r0,r6,r9
|
|
|
|
|
xor r0,r0,r0
|
2005-11-11 10:15:21 +00:00
|
|
|
add r3,r3,r0
|
|
|
|
|
ld r0,CFG_TB_UPDATE_COUNT(r3)
|
|
|
|
|
cmpld cr0,r0,r8 /* check if updated */
|
|
|
|
|
bne- 50b
|
2017-10-16 05:49:14 +00:00
|
|
|
b 78f
|
2005-11-11 10:15:21 +00:00
|
|
|
|
2017-10-16 05:49:14 +00:00
|
|
|
/*
|
|
|
|
|
* For coarse clocks we get data directly from the vdso data page, so
|
|
|
|
|
* we don't need to call __do_get_tspec, but we still need to do the
|
|
|
|
|
* counter trick.
|
|
|
|
|
*/
|
|
|
|
|
70: ld r8,CFG_TB_UPDATE_COUNT(r3)
|
|
|
|
|
andi. r0,r8,1 /* pending update ? loop */
|
|
|
|
|
bne- 70b
|
|
|
|
|
add r3,r3,r0 /* r0 is already 0 */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* CLOCK_REALTIME_COARSE, below values are needed for MONOTONIC_COARSE
|
|
|
|
|
* too
|
|
|
|
|
*/
|
2019-10-27 16:26:55 +00:00
|
|
|
ld r4,STAMP_XTIME_SEC(r3)
|
|
|
|
|
ld r5,STAMP_XTIME_NSEC(r3)
|
2017-10-16 05:49:14 +00:00
|
|
|
bne cr6,75f
|
|
|
|
|
|
|
|
|
|
/* CLOCK_MONOTONIC_COARSE */
|
powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038
Jakub Drnec reported:
Setting the realtime clock can sometimes make the monotonic clock go
back by over a hundred years. Decreasing the realtime clock across
the y2k38 threshold is one reliable way to reproduce. Allegedly this
can also happen just by running ntpd, I have not managed to
reproduce that other than booting with rtc at >2038 and then running
ntp. When this happens, anything with timers (e.g. openjdk) breaks
rather badly.
And included a test case (slightly edited for brevity):
#define _POSIX_C_SOURCE 199309L
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>
long get_time(void) {
struct timespec tp;
clock_gettime(CLOCK_MONOTONIC, &tp);
return tp.tv_sec + tp.tv_nsec / 1000000000;
}
int main(void) {
long last = get_time();
while(1) {
long now = get_time();
if (now < last) {
printf("clock went backwards by %ld seconds!\n", last - now);
}
last = now;
sleep(1);
}
return 0;
}
Which when run concurrently with:
# date -s 2040-1-1
# date -s 2037-1-1
Will detect the clock going backward.
The root cause is that wtom_clock_sec in struct vdso_data is only a
32-bit signed value, even though we set its value to be equal to
tk->wall_to_monotonic.tv_sec which is 64-bits.
Because the monotonic clock starts at zero when the system boots the
wall_to_montonic.tv_sec offset is negative for current and future
dates. Currently on a freshly booted system the offset will be in the
vicinity of negative 1.5 billion seconds.
However if the wall clock is set past the Y2038 boundary, the offset
from wall to monotonic becomes less than negative 2^31, and no longer
fits in 32-bits. When that value is assigned to wtom_clock_sec it is
truncated and becomes positive, causing the VDSO assembly code to
calculate CLOCK_MONOTONIC incorrectly.
That causes CLOCK_MONOTONIC to jump ahead by ~4 billion seconds which
it is not meant to do. Worse, if the time is then set back before the
Y2038 boundary CLOCK_MONOTONIC will jump backward.
We can fix it simply by storing the full 64-bit offset in the
vdso_data, and using that in the VDSO assembly code. We also shuffle
some of the fields in vdso_data to avoid creating a hole.
The original commit that added the CLOCK_MONOTONIC support to the VDSO
did actually use a 64-bit value for wtom_clock_sec, see commit
a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to
32 bits kernel") (Nov 2005). However just 3 days later it was
converted to 32-bits in commit 0c37ec2aa88b ("[PATCH] powerpc: vdso
fixes (take #2)"), and the bug has existed since then AFAICS.
Fixes: 0c37ec2aa88b ("[PATCH] powerpc: vdso fixes (take #2)")
Cc: stable@vger.kernel.org # v2.6.15+
Link: http://lkml.kernel.org/r/HaC.ZfES.62bwlnvAvMP.1STMMj@seznam.cz
Reported-by: Jakub Drnec <jaydee@email.cz>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-03-13 13:14:38 +00:00
|
|
|
ld r6,WTOM_CLOCK_SEC(r3)
|
2017-10-16 05:49:14 +00:00
|
|
|
lwa r9,WTOM_CLOCK_NSEC(r3)
|
|
|
|
|
|
|
|
|
|
/* check if counter has updated */
|
|
|
|
|
or r0,r6,r9
|
|
|
|
|
75: or r0,r0,r4
|
|
|
|
|
or r0,r0,r5
|
|
|
|
|
xor r0,r0,r0
|
|
|
|
|
add r3,r3,r0
|
|
|
|
|
ld r0,CFG_TB_UPDATE_COUNT(r3)
|
|
|
|
|
cmpld cr0,r0,r8 /* check if updated */
|
|
|
|
|
bne- 70b
|
|
|
|
|
|
|
|
|
|
/* Counter has not updated, so continue calculating proper values for
|
|
|
|
|
* sec and nsec if monotonic coarse, or just return with the proper
|
|
|
|
|
* values for realtime.
|
2005-11-11 10:15:21 +00:00
|
|
|
*/
|
2017-10-16 05:49:14 +00:00
|
|
|
bne cr6,80f
|
|
|
|
|
|
|
|
|
|
/* Add wall->monotonic offset and check for overflow or underflow */
|
|
|
|
|
78: add r4,r4,r6
|
|
|
|
|
add r5,r5,r9
|
|
|
|
|
cmpd cr0,r5,r7
|
|
|
|
|
cmpdi cr1,r5,0
|
|
|
|
|
blt 79f
|
|
|
|
|
subf r5,r7,r5
|
|
|
|
|
addi r4,r4,1
|
|
|
|
|
79: bge cr1,80f
|
|
|
|
|
addi r4,r4,-1
|
|
|
|
|
add r5,r5,r7
|
2008-10-27 23:56:03 +00:00
|
|
|
|
|
|
|
|
80: std r4,TSPC64_TV_SEC(r11)
|
|
|
|
|
std r5,TSPC64_TV_NSEC(r11)
|
2005-11-11 10:15:21 +00:00
|
|
|
|
|
|
|
|
mtlr r12
|
2005-11-16 02:54:32 +00:00
|
|
|
crclr cr0*4+so
|
2005-11-11 10:15:21 +00:00
|
|
|
li r3,0
|
|
|
|
|
blr
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* syscall fallback
|
|
|
|
|
*/
|
|
|
|
|
99:
|
|
|
|
|
li r0,__NR_clock_gettime
|
2018-09-14 03:40:04 +00:00
|
|
|
.cfi_restore lr
|
2005-11-11 10:15:21 +00:00
|
|
|
sc
|
|
|
|
|
blr
|
|
|
|
|
.cfi_endproc
|
|
|
|
|
V_FUNCTION_END(__kernel_clock_gettime)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Exact prototype of clock_getres()
|
|
|
|
|
*
|
|
|
|
|
* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
V_FUNCTION_BEGIN(__kernel_clock_getres)
|
|
|
|
|
.cfi_startproc
|
|
|
|
|
/* Check for supported clock IDs */
|
|
|
|
|
cmpwi cr0,r3,CLOCK_REALTIME
|
|
|
|
|
cmpwi cr1,r3,CLOCK_MONOTONIC
|
2005-11-14 03:55:58 +00:00
|
|
|
cror cr0*4+eq,cr0*4+eq,cr1*4+eq
|
2005-11-11 10:15:21 +00:00
|
|
|
bne cr0,99f
|
|
|
|
|
|
2019-12-02 07:57:29 +00:00
|
|
|
mflr r12
|
|
|
|
|
.cfi_register lr,r12
|
|
|
|
|
bl V_LOCAL_FUNC(__get_datapage)
|
|
|
|
|
lwz r5, CLOCK_HRTIMER_RES(r3)
|
|
|
|
|
mtlr r12
|
2005-11-11 10:15:21 +00:00
|
|
|
li r3,0
|
2016-09-25 07:16:53 +00:00
|
|
|
cmpldi cr0,r4,0
|
2005-11-16 02:54:32 +00:00
|
|
|
crclr cr0*4+so
|
2005-11-11 10:15:21 +00:00
|
|
|
beqlr
|
|
|
|
|
std r3,TSPC64_TV_SEC(r4)
|
|
|
|
|
std r5,TSPC64_TV_NSEC(r4)
|
|
|
|
|
blr
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* syscall fallback
|
|
|
|
|
*/
|
|
|
|
|
99:
|
|
|
|
|
li r0,__NR_clock_getres
|
|
|
|
|
sc
|
|
|
|
|
blr
|
|
|
|
|
.cfi_endproc
|
|
|
|
|
V_FUNCTION_END(__kernel_clock_getres)
|
|
|
|
|
|
2013-04-22 09:29:33 +00:00
|
|
|
/*
|
|
|
|
|
* Exact prototype of time()
|
|
|
|
|
*
|
|
|
|
|
* time_t time(time *t);
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
V_FUNCTION_BEGIN(__kernel_time)
|
|
|
|
|
.cfi_startproc
|
|
|
|
|
mflr r12
|
|
|
|
|
.cfi_register lr,r12
|
|
|
|
|
|
|
|
|
|
mr r11,r3 /* r11 holds t */
|
|
|
|
|
bl V_LOCAL_FUNC(__get_datapage)
|
|
|
|
|
|
2019-10-27 16:26:55 +00:00
|
|
|
ld r4,STAMP_XTIME_SEC(r3)
|
2013-04-22 09:29:33 +00:00
|
|
|
|
|
|
|
|
cmpldi r11,0 /* check if t is NULL */
|
|
|
|
|
beq 2f
|
|
|
|
|
std r4,0(r11) /* store result at *t */
|
|
|
|
|
2: mtlr r12
|
|
|
|
|
crclr cr0*4+so
|
|
|
|
|
mr r3,r4
|
|
|
|
|
blr
|
|
|
|
|
.cfi_endproc
|
|
|
|
|
V_FUNCTION_END(__kernel_time)
|
|
|
|
|
|
2005-11-11 10:15:21 +00:00
|
|
|
|
|
|
|
|
/*
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
* This is the core of clock_gettime() and gettimeofday(),
|
|
|
|
|
* it returns the current time in r4 (seconds) and r5.
|
|
|
|
|
* On entry, r7 gives the resolution of r5, either USEC_PER_SEC
|
|
|
|
|
* or NSEC_PER_SEC, giving r5 in microseconds or nanoseconds.
|
2008-10-27 23:56:03 +00:00
|
|
|
* It expects the datapage ptr in r3 and doesn't clobber it.
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
* It clobbers r0, r6 and r9.
|
2008-10-27 23:56:03 +00:00
|
|
|
* On return, r8 contains the counter value that can be reused.
|
|
|
|
|
* This clobbers cr0 but not any other cr field.
|
|
|
|
|
*/
|
|
|
|
|
V_FUNCTION_BEGIN(__do_get_tspec)
|
|
|
|
|
.cfi_startproc
|
|
|
|
|
/* check for update count & load values */
|
|
|
|
|
1: ld r8,CFG_TB_UPDATE_COUNT(r3)
|
|
|
|
|
andi. r0,r8,1 /* pending update ? loop */
|
|
|
|
|
bne- 1b
|
|
|
|
|
xor r0,r8,r8 /* create dependency */
|
|
|
|
|
add r3,r3,r0
|
|
|
|
|
|
|
|
|
|
/* Get TB & offset it. We use the MFTB macro which will generate
|
|
|
|
|
* workaround code for Cell.
|
|
|
|
|
*/
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
MFTB(r6)
|
2008-10-27 23:56:03 +00:00
|
|
|
ld r9,CFG_TB_ORIG_STAMP(r3)
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
subf r6,r9,r6
|
2008-10-27 23:56:03 +00:00
|
|
|
|
|
|
|
|
/* Scale result */
|
|
|
|
|
ld r5,CFG_TB_TO_XS(r3)
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
sldi r6,r6,12 /* compute time since stamp_xtime */
|
|
|
|
|
mulhdu r6,r6,r5 /* in units of 2^-32 seconds */
|
2008-10-27 23:56:03 +00:00
|
|
|
|
|
|
|
|
/* Add stamp since epoch */
|
2019-10-27 16:26:55 +00:00
|
|
|
ld r4,STAMP_XTIME_SEC(r3)
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
lwz r5,STAMP_SEC_FRAC(r3)
|
2008-10-27 23:56:03 +00:00
|
|
|
or r0,r4,r5
|
|
|
|
|
or r0,r0,r6
|
|
|
|
|
xor r0,r0,r0
|
|
|
|
|
add r3,r3,r0
|
|
|
|
|
ld r0,CFG_TB_UPDATE_COUNT(r3)
|
|
|
|
|
cmpld r0,r8 /* check if updated */
|
|
|
|
|
bne- 1b /* reload if so */
|
|
|
|
|
|
|
|
|
|
/* convert to seconds & nanoseconds and add to stamp */
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
add r6,r6,r5 /* add on fractional seconds of xtime */
|
|
|
|
|
mulhwu r5,r6,r7 /* compute micro or nanoseconds and */
|
2008-10-27 23:56:03 +00:00
|
|
|
srdi r6,r6,32 /* seconds since stamp_xtime */
|
powerpc: Rework VDSO gettimeofday to prevent time going backwards
Currently it is possible for userspace to see the result of
gettimeofday() going backwards by 1 microsecond, assuming that
userspace is using the gettimeofday() in the VDSO. The VDSO
gettimeofday() algorithm computes the time in "xsecs", which are
units of 2^-20 seconds, or approximately 0.954 microseconds,
using the algorithm
now = (timebase - tb_orig_stamp) * tb_to_xs + stamp_xsec
and then converts the time in xsecs to seconds and microseconds.
The kernel updates the tb_orig_stamp and stamp_xsec values every
tick in update_vsyscall(). If the length of the tick is not an
integer number of xsecs, then some precision is lost in converting
the current time to xsecs. For example, with CONFIG_HZ=1000, the
tick is 1ms long, which is 1048.576 xsecs. That means that
stamp_xsec will advance by either 1048 or 1049 on each tick.
With the right conditions, it is possible for userspace to get
(timebase - tb_orig_stamp) * tb_to_xs being 1049 if the kernel is
slightly late in updating the vdso_datapage, and then for stamp_xsec
to advance by 1048 when the kernel does update it, and for userspace
to then see (timebase - tb_orig_stamp) * tb_to_xs being zero due to
integer truncation. The result is that time appears to go backwards
by 1 microsecond.
To fix this we change the VDSO gettimeofday to use a new field in the
VDSO datapage which stores the nanoseconds part of the time as a
fractional number of seconds in a 0.32 binary fraction format.
(Or put another way, as a 32-bit number in units of 0.23283 ns.)
This is convenient because we can use the mulhwu instruction to
convert it to either microseconds or nanoseconds.
Since it turns out that computing the time of day using this new field
is simpler than either using stamp_xsec (as gettimeofday does) or
stamp_xtime.tv_nsec (as clock_gettime does), this converts both
gettimeofday and clock_gettime to use the new field. The existing
__do_get_tspec function is converted to use the new field and take
a parameter in r7 that indicates the desired resolution, 1,000,000
for microseconds or 1,000,000,000 for nanoseconds. The __do_get_xsec
function is then unused and is deleted.
The new algorithm is
now = ((timebase - tb_orig_stamp) << 12) * tb_to_xs
+ (stamp_xtime_seconds << 32) + stamp_sec_fraction
with 'now' in units of 2^-32 seconds. That is then converted to
seconds and either microseconds or nanoseconds with
seconds = now >> 32
partseconds = ((now & 0xffffffff) * resolution) >> 32
The 32-bit VDSO code also makes a further simplification: it ignores
the bottom 32 bits of the tb_to_xs value, which is a 0.64 format binary
fraction. Doing so gets rid of 4 multiply instructions. Assuming
a timebase frequency of 1GHz or less and an update interval of no
more than 10ms, the upper 32 bits of tb_to_xs will be at least
4503599, so the error from ignoring the low 32 bits will be at most
2.2ns, which is more than an order of magnitude less than the time
taken to do gettimeofday or clock_gettime on our fastest processors,
so there is no possibility of seeing inconsistent values due to this.
This also moves update_gtod() down next to its only caller, and makes
update_vsyscall use the time passed in via the wall_time argument rather
than accessing xtime directly. At present, wall_time always points to
xtime, but that could change in future.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-06-20 19:03:08 +00:00
|
|
|
clrldi r5,r5,32
|
2008-10-27 23:56:03 +00:00
|
|
|
add r4,r4,r6
|
|
|
|
|
blr
|
|
|
|
|
.cfi_endproc
|
|
|
|
|
V_FUNCTION_END(__do_get_tspec)
|
