All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: Jan Ceuleers <jan.ceuleers@computer.org>
Cc: John Stultz <johnstul@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/6] hrtimer: Provide clock_was_set_delayed()
Date: Thu, 12 Jul 2012 08:29:54 -0400	[thread overview]
Message-ID: <4FFEC342.2060107@redhat.com> (raw)
In-Reply-To: <4FFE804A.8070205@computer.org>



On 07/12/2012 03:44 AM, Jan Ceuleers wrote:
> On 07/11/2012 06:47 PM, John Stultz wrote:
>> I'll see if my worry is unfounded, but it might be a bit too clever for rare events.
> 
> Full ACK.
> 
> There is an unfortunate history of critical-to-moderately-serious bugs in
> the leap second handling, so I submit that what is needed is a simple,
> obviously-correct and robust mechanism. Robust statically, but also in the
> face of code churn because these code paths are exercised so rarely out in
> the wild.
> 
> Just my opinion, FWIW.
> 

Ditto - and it's not just FWIW.

John (and everyone else), I think we're over-thinking this.  Would it be nice to
get an extremely elegant solution to this?  Yeah ... it would.  But the reality
is that we're not going to get there and IMO we're making things too complex for
this little piece of code.

Acked-by: Prarit Bhargava <prarit@redhat.com>

IMO, this is the simplest way to move forward with this code.

P.


  reply	other threads:[~2012-07-12 12:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-10 22:43 [PATCH 0/6] Fix for leapsecond caused hrtimer/futex issue (updated) John Stultz
2012-07-10 22:43 ` [PATCH 1/6] hrtimer: Provide clock_was_set_delayed() John Stultz
2012-07-11 12:15   ` Prarit Bhargava
2012-07-11 12:45     ` Thomas Gleixner
2012-07-11 13:05       ` Peter Zijlstra
2012-07-11 15:18         ` Thomas Gleixner
2012-07-11 15:56           ` Peter Zijlstra
2012-07-11 16:47           ` John Stultz
2012-07-12  7:44             ` Jan Ceuleers
2012-07-12 12:29               ` Prarit Bhargava [this message]
2012-07-11 13:05       ` Prarit Bhargava
2012-07-11 13:38         ` Peter Zijlstra
2012-07-11 21:40   ` [tip:timers/urgent] " tip-bot for John Stultz
2012-07-10 22:43 ` [PATCH 2/6] timekeeping: Fix leapsecond triggered load spike issue John Stultz
2012-07-11 21:41   ` [tip:timers/urgent] " tip-bot for John Stultz
2012-07-10 22:43 ` [PATCH 3/6] timekeeping: Maintain ktime_t based offsets for hrtimers John Stultz
2012-07-11 21:42   ` [tip:timers/urgent] " tip-bot for Thomas Gleixner
2012-07-10 22:43 ` [PATCH 4/6] hrtimer: Move lock held region in hrtimer_interrupt() John Stultz
2012-07-10 22:43 ` [PATCH 4/6] hrtimers: " John Stultz
2012-07-11 21:43   ` [tip:timers/urgent] " tip-bot for Thomas Gleixner
2012-07-10 22:43 ` [PATCH 5/6] timekeeping: Provide hrtimer update function John Stultz
2012-07-11 21:44   ` [tip:timers/urgent] " tip-bot for Thomas Gleixner
2012-07-10 22:43 ` [PATCH 6/6] hrtimer: Update hrtimer base offsets each hrtimer_interrupt John Stultz
2012-07-11 21:45   ` [tip:timers/urgent] " tip-bot for John Stultz
2012-07-15 15:22   ` [PATCH 6/6] " Andreas Schwab
2012-07-15 15:22     ` Andreas Schwab
2012-07-15 20:28     ` Rafael J. Wysocki
2012-07-15 20:28       ` Rafael J. Wysocki
     [not found]   ` <m2y5mlnj5z.fsf__49536.0585897744$1342365803$gmane$org@igel.home>
2012-07-15 16:02     ` Andreas Schwab
2012-07-10 22:53 ` [PATCH 0/6] Fix for leapsecond caused hrtimer/futex issue (updated) John Stultz
2012-07-12 22:43   ` Jiri Bohac
2012-07-12 23:58     ` John Stultz
2012-07-10 23:00 ` John Stultz
2012-07-13  0:43   ` John Stultz
2012-07-11 10:59 ` Peter Zijlstra
2012-07-11 11:17 ` Ingo Molnar
2012-07-12 12:32   ` Prarit Bhargava
2012-07-11 12:16 ` Prarit Bhargava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FFEC342.2060107@redhat.com \
    --to=prarit@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=jan.ceuleers@computer.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.