linux-kernel - Re: [PATCH RFC V1 0/5] Rationalize time keeping

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]

Date:	Thu, 03 May 2012 12:42:07 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Richard Cochran <richardcochran@...il.com>
CC:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH RFC V1 0/5] Rationalize time keeping

On 05/03/2012 12:28 PM, Richard Cochran wrote:
> On Thu, May 03, 2012 at 11:44:45AM -0700, John Stultz wrote:
>> But the changes you make to getnstimeofday() still needs to happen
>> in the vDSO code. The vDSO code basically implements
>> getnstimeofday() in userland.
>>
>> If you're code is trying to make it so that the leap-second is
>> properly handled at the second boundary instead of the tick
>> boundary, there must me some change needed to the vDSO, since the
>> vDSO code is updated only each tick. Otherwise how can you enforce
>> the leap after the second boundary but before the tick?
> Yeah, so the vDSO does the sub-tick interpolation, and this can easily
> miss an inserted leap second for a while (just like the current code).
>
> So, this patch series as it stands improves the users of the
> traditional syscalls without hurting the superduper vDSO performance
> at all. The vDSO leap second time errors are not fixed, but they are
> also no worse than today, either.
>
> I am try to say that, even if there is resistance to adding code in
> the vDSO path for reasons of performance, that doesn't necessarily
> mean that we cannot fix the leap second for the tradition syscall
> case.
But this also has the same drawback of only fixing the adjtimex() path, 
in that applications that mix calls to gettimeofday or adjtimex will see 
different behavior in that tick interval.  I'd also try to avoid any 
disparity between the syscall and vdso syscall implementations, as 
they're supposed to be identical.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/