Re: [RFC][PATCH 0/4] Fixes for leapsecond expiring early ABS_TIME CLOCK_REALTIME timers

[John Stultz]

On Mon, Jun 1, 2015 at 3:29 PM, Daniel Bristot de Oliveira
<bristot@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/