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, 3 May 2012 21:28:24 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH RFC V1 0/5] Rationalize time keeping

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.

Richard
--
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/