linux-kernel - Re: [RFC][PATCH 0/4] Fixes for leapsecond expiring early ABS_TIME CLOCK

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: <CALAqxLVnt30rcB2goY_OxVohBDgBEv5nAJJFydtUa+7HTfz3WA@mail.gmail.com>
Date:	Mon, 1 Jun 2015 23:19:53 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Daniel Bristot de Oliveira <bristot@...hat.com>
Cc:	Prarit Bhargava <prarit@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Richard Cochran <richardcochran@...il.com>,
	Jan Kara <jack@...e.cz>, Jiri Bohac <jbohac@...e.cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Shuah Khan <shuahkh@....samsung.com>
Subject: Re: [RFC][PATCH 0/4] Fixes for leapsecond expiring early ABS_TIME
 CLOCK_REALTIME timers

On Mon, Jun 1, 2015 at 3:29 PM, Daniel Bristot de Oliveira
<bristot@...hat.com> wrote:
>
>
> Il 01/06/2015 18:42, Prarit Bhargava ha scritto:
>> Daniel, did you disable chronyd/ntpd?  I've seen both failures if I leave
>> chronyd running.
>>
>> P.
>
> Prarit, John, that is it, chronyd was running.

I reproduced this with chronyd running in the background, and while
its unlikely to be an edge case anyone would hit in normal usage, I'm
looking at how to ensure the adjtimex state is handled better.

It basically comes down to chrony modifying the timex.time_status
removing the STA_INS flag, which doesn't get processed to change the
time_state from TIME_INS -> TIME_OK until the next second_overflow().
Since STA_INS flag is not present, the leap-second is not applied at
the second edge, and we see the strange TIME_INS state run through
what should be the leapsecond.

Mostly this is an issue with the test not printing the time_status
details, so the output looks especially confusing.  Richard's point
about modifying the time_state immediately when the STA_INS flag is
dropped by adjtimex, rather then waiting for the next second_overflow
call would likely make this case more sensible as well.

But again, this is a problematic edge case of two adjtimex controllers
running at the same time, which isn't really valid to begin with, so
I'm less worried about trying to get this issue fixed and into
-stable, and am fine with improving it via a test output change or via
a separate patch to change the time_state state machine.

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/