From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752429AbbBKKrS (ORCPT ); Wed, 11 Feb 2015 05:47:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49466 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751518AbbBKKrQ (ORCPT ); Wed, 11 Feb 2015 05:47:16 -0500 Message-ID: <54DB332A.10108@redhat.com> Date: Wed, 11 Feb 2015 05:47:06 -0500 From: Prarit Bhargava User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: John Stultz CC: lkml , Thomas Gleixner , Miroslav Lichvar Subject: Re: [PATCH] time, ntp: Do not update time_state in middle of leap second References: <1423333779-9857-1-git-send-email-prarit@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/10/2015 06:47 PM, John Stultz wrote: > On Sun, Feb 8, 2015 at 2:29 AM, Prarit Bhargava wrote: >> During leap second insertion testing it was noticed that a small window >> exists where the time_state could be reset such that >> time_state = TIME_OK, which then causes the leap second to not occur, or >> causes the entire leap second state machine to fail. > > > I think this description is fairly opaque, and probably needs the > specific example of the state change transitions that motivates this > patch. > >> While this is highly unlikely to ever happen in the real world it is >> still something we should protect against, as breaking the state machine >> is obviously bad. > > In this case it was a test-case bug where uninitialized data being > passed to adjtimex (when the test intended to only read the time > state) was causing an unexpected state change transition. So its not > immediately obvious that resetting the state machine when the root > called adjtimex is invalid, so it would be good to make this more > clear and explicit (ie: show the expected state transitions and the > command that caused the strange transition you saw). > > Sorry for the slow response here, I've been on the fence as to if this > is the right thing or not, and have needed to get some time to stare > at this a bit more to see if I can convince myself its the right > thing, so improving the commit message might make it more obvious to > me and others. :) Will do :) I'll write up a proper and detailed description. My bad. P. > > thanks > -john >