[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4FEFDFB5.9070404@us.ibm.com>
Date: Sat, 30 Jun 2012 22:27:17 -0700
From: John Stultz <johnstul@...ibm.com>
To: Ben Hutchings <ben@...adent.org.uk>
CC: Richard Cochran <richardcochran@...il.com>,
Jonathan Nieder <jrnieder@...il.com>, stable@...r.kernel.org,
Sasha Levin <levinsasha928@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Dave Jones <davej@...hat.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -stable] ntp: Correct TAI offset during leap second
On 06/30/2012 06:28 PM, Ben Hutchings wrote:
> On Mon, 2012-06-18 at 14:55 +0100, Ben Hutchings wrote:
>> On Sun, 2012-06-17 at 19:34 +0200, Richard Cochran wrote:
>>> On Sun, Jun 17, 2012 at 11:47:51AM -0500, Jonathan Nieder wrote:
>>>> Ben Hutchings wrote:
>>>>> On Fri, 2012-06-15 at 11:56 -0700, John Stultz wrote:
>>>>>> commit dd48d708ff3e917f6d6b6c2b696c3f18c019feed upstream.
>>>> [...]
>>>>> This doesn't apply to 3.2.y, unsurprisingly. Let me know if there are
>>>>> any urgent leap second fixes that will be needed there.
>>>> 6b43ae8a619d (ntp: Fix leap-second hrtimer livelock) sounds important,
>>>> but the patch depends on bd3312681f69 (ntp: Add ntp_lock to replace
>>>> xtime_locking) which does not have a commit message explaining its
>>>> purpose (and that patch in turn depends on ea7cf49a7633).
>> If I understand the commit message for 6b43ae8a619d correctly, the
>> livelock results from ntp_lock and xtime_lock being acquired in opposite
>> orders in two threads. Which means it wasn't possible before ntp_lock
>> was introduced in bd3312681f69.
> [...]
>
> Apparently some other livelock was possible, though I was unable to
> reproduce it myself. Some proportion of systems running 2.6.32 or 3.2
> (not sure about the intermediate stable-supported versions) are reported
> to have locked up, either in adjtimex or during the leap second.
Ugh. That sucks. Any more details as they come in would be helpful,
specifically around the exact kernel versions affected.
> I understand that we might not have so long to wait for the next leap
> second, so if anyone understands what fixes are still needed in stable
> updates I would really appreciate that.
Yea. I'm digging now to try to see what could be happening.
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/
Powered by blists - more mailing lists