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:	Sat, 5 May 2012 09:34:08 +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 12:57:40PM -0700, John Stultz wrote:
> On 04/27/2012 01:12 AM, Richard Cochran wrote:
> >
> >The basic idea is to keep the internal time using a continuous
> >timescale and to convert to UTC by testing the time value against the
> >current threshold and adding the appropriate offset. Since the UTC
> >time and the leap second status is provided on demand, this eliminates
> >the need to set a timer or to constantly monitor for leap seconds, as
> >was done up until now.
> 
> So as I mentioned in my earlier review of this patch set, I'm not as
> excited about the meta-layer you added in utc-tai.h.

It really isn't a layer. It is just a pair of static inline helper
functions. The code could just as well be internal to timekeeper.c,
but I put it in its own file so that I could include it into a unit
test program.

> http://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=shortlog;h=refs/heads/dev/clktai
> 
> The untested patch set there basically pushes TAI time management
> into the timekeeping core, and then exports a CLOCK_TAI clockid.
> 
> This patch set *does not* address the tick-granularity delayed
> leap-second processing issue that your patch also addresses. But I
> feel like the basic handling of tai is a little simpler.

So, is this a "won't fix" issue, in your view?

(If so, I'll drop it.)
 
> Take a look at it and let me know what you think.

It looks okay to me, as far as it goes.

At least you offer a clock that doesn't jump around. With your patches
(and the TAI offset fix before), user space programs sensitive to the
leap second uglies would have a reasonable option. Data collection
programs can read and store TAI time stamps, and these can always be
converted into UTC using a table method.

But do you think it will be possible to implement the following in the
same way?

- clock_settime(CLOCK_TAI)
- clock_adjtime(CLOCK_TAI)
- timer_create(CLOCK_TAI)

Thanks,
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/