linux-kernel - Re: [PATCH] timekeeping: Fix 1ns/tick drift with GENERIC_TIME_VSYSCALL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <574ECA5C.4040005@omicronenergy.com>
Date:	Wed, 1 Jun 2016 13:43:24 +0200
From:	Thomas Graziadei <thomas.graziadei@...cronenergy.com>
To:	John Stultz <john.stultz@...aro.org>
CC:	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tony Luck <tony.luck@...el.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH] timekeeping: Fix 1ns/tick drift with
 GENERIC_TIME_VSYSCALL_OLD

On 06/01/2016 01:11 AM, John Stultz wrote:
> On Tue, May 31, 2016 at 6:06 AM, Thomas Graziadei
> <thomas.graziadei@...cronenergy.com> wrote:
>> From: Thomas Graziadei <thomas.graziadei@...cronenergy.com>
>>
>> The user notices the problem in a raw and real time drift, calling
>> clock_gettime with CLOCK_REALTIME / CLOCK_MONOTONIC_RAW on a system
>> with no ntp correction taking place (no ntpd or ptp stuff running).
>
> Hmm.. Curious. Was it actually drifting, or was it just
> oscillating/ringing near the RAW clock's value?

It is actually drifting.

This is the output from a little test program:

realtime  : 1464775074:846282133
raw time  : 1054:851963700
drift_real: 999402ns

total duration: 1000s 158517540ns

>
>> The problem is, that old_vsyscall_fixup adds an extra 1ns even though
>> xtime_nsec is already held in full nsecs and the remainder in this
>> case is 0. Do the rounding up buisness only if needed.
>
> The patch looks ok. But I'm curious what architecture you were seeing
> this on (ia64, powerpc?), as it would be much nicer to have those
> architectures migrate off of the old low-res vsyscall calculation and
> use the newer method with sub-ns precision, instead of trying to
> further fix up the deprecated method.
>
> I had submitted a patch to convert ia64 awhile back, but I don't
> recall getting much feedback.
>

We are using a powerpc architecture.

I guess you are right, it would be nicer to use the new method but then 
on the other hand, this timing topic is rather new to me.

> thanks
> -john
>

thanks,
Thomas