diff options
| -rw-r--r-- | arch/x86/kernel/tsc.c | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index db697b81b8b1..1e6244202612 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c | |||
| @@ -769,13 +769,14 @@ static cycle_t __vsyscall_fn vread_tsc(void) | |||
| 769 | cycle_t ret; | 769 | cycle_t ret; |
| 770 | 770 | ||
| 771 | /* | 771 | /* |
| 772 | * Surround the RDTSC by barriers, to make sure it's not | 772 | * Empirically, a fence (of type that depends on the CPU) |
| 773 | * speculated to outside the seqlock critical section and | 773 | * before rdtsc is enough to ensure that rdtsc is ordered |
| 774 | * does not cause time warps: | 774 | * with respect to loads. The various CPU manuals are unclear |
| 775 | * as to whether rdtsc can be reordered with later loads, | ||
| 776 | * but no one has ever seen it happen. | ||
| 775 | */ | 777 | */ |
| 776 | rdtsc_barrier(); | 778 | rdtsc_barrier(); |
| 777 | ret = (cycle_t)vget_cycles(); | 779 | ret = (cycle_t)vget_cycles(); |
| 778 | rdtsc_barrier(); | ||
| 779 | 780 | ||
| 780 | return ret >= VVAR(vsyscall_gtod_data).clock.cycle_last ? | 781 | return ret >= VVAR(vsyscall_gtod_data).clock.cycle_last ? |
| 781 | ret : VVAR(vsyscall_gtod_data).clock.cycle_last; | 782 | ret : VVAR(vsyscall_gtod_data).clock.cycle_last; |
