linux-kernel - Re: [PATCH RFC V2 3/6] time: keep track of the pending utc/tai threshold

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: <4FBBD591.1000103@linaro.org>
Date:	Tue, 22 May 2012 11:06:09 -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 V2 3/6] time: keep track of the pending utc/tai threshold

On 05/22/2012 10:39 AM, Richard Cochran wrote:
> On Mon, May 21, 2012 at 09:08:15PM +0200, Richard Cochran wrote:
>> On Mon, May 21, 2012 at 11:09:51AM -0700, John Stultz wrote:
>>> On 05/18/2012 07:09 AM, Richard Cochran wrote:
>>>> +	/* Tracks where we stand with regard to leap the second epoch. */
>>>> +	enum {
>>>> +		LEAP_IDLE,
>>>> +		LEAP_INS_PENDING,
>>>> +		LEAP_INS_DONE,
>>>> +		LEAP_DEL_PENDING,
>>>> +		LEAP_DEL_DONE,
>>>> +	} leap_state;
> ...
>
>> I don't think I am explaining this very well. I will try again to make
>> it clear using a table or something later on.
> The following table illustrates what happens around a (fictitious)
> leap second. Imagine a new epoch will occur at UTC time value 10 and
> the new TAI - UTC offset will be 2 seconds. The columns of the table
> show the values of the relevant time variables.
>
> U:     UTC time
> CODE:  NTP time code
> T:     TAI - UTC offset
> P:     pending (explained below)
>
>     U   CODE    T   P
>   --------------------
>     1   INS     1   1  leap second sheduled
>   --------------------
>     2   INS     1   1
>   --------------------
>         ...
>   --------------------
>     8   INS     1   1
>   --------------------
>     9   INS     1   1
>   --------------------
> | 10   OOP     1   1  leap second, 1st tick
> |~~~~~~~~~~~~~~~~~~~
> |  9           2   0  leap second, 2nd and subsequent ticks
>   --------------------
>    10   WAIT    2   0  new epoch
>   --------------------
>    11   WAIT    2   0

Not sure I'm still following.

It seems currently we have:

    U   CODE    T
  ----------------
    9   INS     1
  ----------------
   10   INS     1     pre tick, post leap second edge (this is the technically incorrect interval)
  ~~~~~~~~~~~~~~~~
    9   OOP     2     post tick, post leap second edge
  ----------------
   10   WAIT    2     new epoch


If you're trying to correct the pre-tick, post leap second edge, the above provides all you need.

In the adjtimex code, all you have to do is:


if (unlikely(CODE == INS&&  U == 10))

	/*note, we're not modifying state here, just returning corrected local values*/

	return (U-1, OOP, T+1);

return (U,CODE, T);


Since when the tick triggers, we'll move the CODE state appropriately.

Or am I still missing something?

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/