linux-kernel - Re: [PATCH 4/5] ntp: Do leapsecond adjustment in adjtimex read path

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:	Fri, 12 Jun 2015 09:37:11 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	linux-kernel@...r.kernel.org, Prarit Bhargava <prarit@...hat.com>,
	Daniel Bristot de Oliveira <bristot@...hat.com>,
	Jan Kara <jack@...e.cz>, Jiri Bohac <jbohac@...e.cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH 4/5] ntp: Do leapsecond adjustment in adjtimex read path

John,

The description is just awful.

On Thu, Jun 11, 2015 at 03:54:56PM -0700, John Stultz wrote:
> Since the leapsecond is applied at tick-time, this
> means there is a small window of time at the start
> of a leap-second where we cross into the next second
> before applying the leap.

First you say the leap second is applied at the tick, ...

> This patch modified adjtimex so that the leap-second
> is applied on the second edge. Providing more correct
> leapsecond behavior.

and then you say it is applied on the edge of the second.

Instead, this second paragraph should say:

   This patch modifies adjtimex to apply the leap second
   correction to the returned time value.  Callers of adjtimex
   will observe the leap second occuring exactly on the edge
   of the second.

> This does make it so that adjtimex()'s returned time
> values can be inconsistent with time values read from
> gettimeofday() or clock_gettime(CLOCK_REALTIME,...)
> for a brief period of one tick at the leapsecond.

How about this instead?

   As as a result, adjtimex()'s returned time values will be
   inconsistent with time values read from gettimeofday() or
   clock_gettime(CLOCK_REALTIME,...) for a brief period of one
   tick at the leapsecond.

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/