Should these be in -stable ? Looks like all the other recent changes
in that area are present. With the leap second just two weeks away,
it seems like they should be.
Looks like 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d is in 3.4-stable,
(haven't checked earlier -stable trees).
Were there any other patches I missed ?
Dave
commit dd48d708ff3e917f6d6b6c2b696c3f18c019feed
Author: Richard Cochran <[email protected]>
Date: Thu Apr 26 14:11:32 2012 +0200
ntp: Correct TAI offset during leap second
When repeating a UTC time value during a leap second (when the UTC
time should be 23:59:60), the TAI timescale should not stop. The kernel
NTP code increments the TAI offset one second too late. This patch fixes
the issue by incrementing the offset during the leap second itself.
Signed-off-by: Richard Cochran <[email protected]>
Signed-off-by: John Stultz <[email protected]>
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index f03fd83..e8c8671 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -412,6 +412,7 @@ int second_overflow(unsigned long secs)
if (secs % 86400 == 0) {
leap = -1;
time_state = TIME_OOP;
+ time_tai++;
printk(KERN_NOTICE
"Clock: inserting leap second 23:59:60 UTC\n");
}
@@ -426,7 +427,6 @@ int second_overflow(unsigned long secs)
}
break;
case TIME_OOP:
- time_tai++;
time_state = TIME_WAIT;
break;
commit fad0c66c4bb836d57a5f125ecd38bed653ca863a
Author: John Stultz <[email protected]>
Date: Wed May 30 10:54:57 2012 -0700
timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond
Commit 6b43ae8a61 (ntp: Fix leap-second hrtimer livelock) broke the
leapsecond update of CLOCK_MONOTONIC. The missing leapsecond update to
wall_to_monotonic causes discontinuities in CLOCK_MONOTONIC.
Adjust wall_to_monotonic when NTP inserted a leapsecond.
Reported-by: Richard Cochran <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Tested-by: Richard Cochran <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6e46cac..6f46a00 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -962,6 +962,7 @@ static cycle_t logarithmic_accumulation(cycle_t offset, int shift)
timekeeper.xtime.tv_sec++;
leap = second_overflow(timekeeper.xtime.tv_sec);
timekeeper.xtime.tv_sec += leap;
+ timekeeper.wall_to_monotonic.tv_sec -= leap;
}
/* Accumulate raw time */
@@ -1077,6 +1078,7 @@ static void update_wall_time(void)
timekeeper.xtime.tv_sec++;
leap = second_overflow(timekeeper.xtime.tv_sec);
timekeeper.xtime.tv_sec += leap;
+ timekeeper.wall_to_monotonic.tv_sec -= leap;
}
timekeeping_update(false);
On 06/15/2012 08:20 AM, Dave Jones wrote:
> Should these be in -stable ? Looks like all the other recent changes
> in that area are present. With the leap second just two weeks away,
> it seems like they should be.
>
> Looks like 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d is in 3.4-stable,
> (haven't checked earlier -stable trees).
So the second patch has been sent out for stable review as of yesterday.
So it should be on its way, but you're right that I forgot to CC stable
on the first TAI offset fix.
I'll generate the patch and send it to Greg. Thanks for the close
review here!
thanks
-john
On Fri, Jun 15, 2012 at 11:48:34AM -0700, John Stultz wrote:
> On 06/15/2012 08:20 AM, Dave Jones wrote:
> > Should these be in -stable ? Looks like all the other recent changes
> > in that area are present. With the leap second just two weeks away,
> > it seems like they should be.
> >
> > Looks like 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d is in 3.4-stable,
> > (haven't checked earlier -stable trees).
>
> So the second patch has been sent out for stable review as of yesterday.
> So it should be on its way, but you're right that I forgot to CC stable
> on the first TAI offset fix.
>
> I'll generate the patch and send it to Greg. Thanks for the close
> review here!
fwiw, I did a test on 3.5rc2 yesterday where I forced a fake leap second at midnight.
Nothing untoward happened, unlike the previous ones :-)
Dave
On Fri, Jun 15, 2012 at 03:09:59PM -0400, Dave Jones wrote:
> On Fri, Jun 15, 2012 at 11:48:34AM -0700, John Stultz wrote:
> > On 06/15/2012 08:20 AM, Dave Jones wrote:
> > > Should these be in -stable ? Looks like all the other recent changes
> > > in that area are present. With the leap second just two weeks away,
> > > it seems like they should be.
> > >
> > > Looks like 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d is in 3.4-stable,
> > > (haven't checked earlier -stable trees).
> >
> > So the second patch has been sent out for stable review as of yesterday.
> > So it should be on its way, but you're right that I forgot to CC stable
> > on the first TAI offset fix.
> >
> > I'll generate the patch and send it to Greg. Thanks for the close
> > review here!
>
> fwiw, I did a test on 3.5rc2 yesterday where I forced a fake leap second at midnight.
> Nothing untoward happened, unlike the previous ones :-)
Out of curiosity, how do you test that? Do you have any programs
specifically for testing the leap second issue?
Thanks,
Richard
On Sat, Jun 16, 2012 at 07:50:09AM +0200, Richard Cochran wrote:
> On Fri, Jun 15, 2012 at 03:09:59PM -0400, Dave Jones wrote:
> > On Fri, Jun 15, 2012 at 11:48:34AM -0700, John Stultz wrote:
> > > On 06/15/2012 08:20 AM, Dave Jones wrote:
> > > > Should these be in -stable ? Looks like all the other recent changes
> > > > in that area are present. With the leap second just two weeks away,
> > > > it seems like they should be.
> > > >
> > > > Looks like 6b43ae8a619d17c4935c3320d2ef9e92bdeed05d is in 3.4-stable,
> > > > (haven't checked earlier -stable trees).
> > >
> > > So the second patch has been sent out for stable review as of yesterday.
> > > So it should be on its way, but you're right that I forgot to CC stable
> > > on the first TAI offset fix.
> > >
> > > I'll generate the patch and send it to Greg. Thanks for the close
> > > review here!
> >
> > fwiw, I did a test on 3.5rc2 yesterday where I forced a fake leap second at midnight.
> > Nothing untoward happened, unlike the previous ones :-)
>
> Out of curiosity, how do you test that? Do you have any programs
> specifically for testing the leap second issue?
no, I just patched the kernel to do this..
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 70b33ab..5f4a1f0 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -396,6 +396,13 @@ int second_overflow(unsigned long secs)
spin_lock_irqsave(&ntp_lock, flags);
+ if (time_state == TIME_OK) {
+ if (secs % 86400 == 0) {
+ printk("Faking leap second.\n");
+ time_state = TIME_INS;
+ }
+ }
+
/*
* Leap second processing. If in leap-insert state at the end of the
* day, the system clock is set back one second; if in leap-delete
and then waited until midnight UTC, and then..
[68242.572516] Faking leap second.
[68242.573379] Clock: inserting leap second 23:59:60 UTC
Dave