linux-kernel - Re: [RFC 0/2] ABI for clock_gettime

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, 22 Dec 2011 13:03:26 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	linux-kernel@...r.kernel.org, Kumar Sundararajan <kumar@...com>,
	Arun Sharma <asharma@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC 0/2] ABI for clock_gettime_ns

On Wed, Dec 14, 2011 at 11:07:46AM -0800, john stultz wrote:
> On Wed, 2011-12-14 at 19:30 +0100, Richard Cochran wrote:
> > 
> > So, you agree on adding new syscalls as a performance tweek?
> 
> Well, the patch that started this off was introducing a new vdso
> function (which had no syscall equivalent) that provided the same data
> as clock_gettime(CLOCK_THREAD_CPUTIME,...) but in ns format, because
> that was a reasonable performance win.

I don't see anything CLOCK_THREAD_CPUTIME in the patches, but I do see
CLOCK_REALTIME and CLOCK_MONOTONIC.

How is this about thread CPU time? (I assumed it was about fast time
stamps.)

> I don't think what is being proposed is trying to limit its use cases.
> The only limitation api wise was if we should return just nanoseconds or
> something with the potential for sub-ns values.

Yes, I do think new interfaces should anticipate sub-ns uses.

> > I mean to define an interface that always returns TAI values, no matter
> > what the clock device.
> 
> Maybe I'm still not understanding, but that seems more limited then what
> is being proposed, at least in my mind. clock_gettime_ns() would still
> take a clockid, so having a CLOCK_TAI would be a potential change in the
> future.

POSIX got the clock_gettime interface wrong, because you cannot tell
the time with it. The POSIX interface will return the same time value
for two consecutive seconds, due to leap seconds.

IMHO, new interfaces should correct this mistake. So, a new interface
providing UTC should also tell the user about leap seconds.

Just my 2 cents,

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/