missing leap second patches in stable.

PATCH Dave Jones 3 participants 5 messages Jun 15, 2012 – Jun 17, 2012 Timekeeping, clocksource core, NTP, alarmtimer

Share & tools

Dave Jones

author

2012-06-15 15:20 UTC #0 lore raw

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]>

kernel/time/ntp.c +1 -1

index f03fd83..e8c8671 100644
@@ -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] open here

Signed-off-by Thomas Gleixner <[email protected]>

kernel/time/timekeeping.c +2 -0

index 6e46cac..6f46a00 100644
@@ -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);

John Stultz

2012-06-15 18:51 UTC #1 lore raw

Quoted 6 lines · Dave Jones

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

Dave Jones

author

2012-06-15 19:10 UTC #2 lore raw

Quoted 8 lines · John Stultz

Quoted 6 lines · Dave Jones
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).

Quoted 6 lines

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

Richard Cochran

2012-06-16 05:50 UTC #3 lore raw

Quoted 13 lines · Dave Jones

Quoted 12 lines · John Stultz
Quoted 6 lines · Dave Jones
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.

Quoted 5 lines

Quoted 2 lines
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

Dave Jones

author

2012-06-17 20:09 UTC #4 lore raw

Quoted 14 lines · Richard Cochran

Quoted 13 lines · Dave Jones
Quoted 12 lines · John Stultz
Quoted 6 lines · Dave Jones
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.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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..

kernel/time/ntp.c +7 -0

index 70b33ab..5f4a1f0 100644
@@ -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