missing leap second patches in stable.

missing leap second patches in stable.

[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).

Were there any other patches I missed ?

	Dave


commit dd48d708ff3e917f6d6b6c2b696c3f18c019feed
Author: Richard Cochran <richardcochran@gmail.com>
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 <richardcochran@gmail.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>

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 <john.stultz@linaro.org>
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 <richardcochran@gmail.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Tested-by: Richard Cochran <richardcochran@gmail.com>
    Cc: stable@kernel.org
    Link: http://lkml.kernel.org/r/1338400497-12420-1-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

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);

Re: missing leap second patches in stable.

[John Stultz]

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

Re: missing leap second patches in stable.

[Dave Jones]

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

Re: missing leap second patches in stable.

[Richard Cochran]

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

Re: missing leap second patches in stable.

[Dave Jones]

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