From: Jan Ceuleers <jan.ceuleers@computer.org>
To: John Stultz <johnstul@us.ibm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] [RFC] Potential fix for leapsecond caused futex related load spikes
Date: Sun, 01 Jul 2012 14:00:28 +0200 [thread overview]
Message-ID: <4FF03BDC.9070208@computer.org> (raw)
In-Reply-To: <1341135371-45034-1-git-send-email-johnstul@us.ibm.com>
On 07/01/2012 11:36 AM, John Stultz wrote:
> I believe this issue is due to the leapsecond being added without
> calling clock_was_set() to notify the hrtimer subsystem of the
> change. (Although I've not yet chased all the way down to the
> hrtimer code to validate exactly what's going on there).
For the benefit of -stable:
Am I right in thinking that, if the analysis is confirmed, this was
caused by the following commit:
commit 746976a301ac9c9aa10d7d42454f8d6cdad8ff2b
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Jul 3 20:05:20 2007 +0200
NTP: remove clock_was_set() call to prevent deadlock
The clock_was_set() call in seconds_overflow() which happens only when
leap seconds are inserted / deleted is wrong in two aspects:
1. it results in a call to on_each_cpu() with interrupts disabled
2. it is potential deadlock source vs. call_lock in smp_call_function()
The only possible side effect of the removal might be, that an absolute
CLOCK_REALTIME timer fires 1 second too late, in the rare case of leap
second deletion and an absolute CLOCK_REALTIME timer which expires in
the affected time frame. It will never fire too early.
This was probably observed by the reporter of a June 30th -> July 1st
hang: http://lkml.org/lkml/2007/7/3/103
A similar problem was observed by Dave Jones, who provided a screen shot
with a lockdep back trace, which allowed to analyse the problem.
Sob: Thomas Gleixner <tglx@linutronix.de>
Ab: Ingo Molnar <mingo@elte.hu>
Sob: Linus Torvalds <torvalds@linux-foundation.org>
next prev parent reply other threads:[~2012-07-01 12:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-01 9:36 [PATCH] [RFC] Potential fix for leapsecond caused futex related load spikes John Stultz
2012-07-01 9:42 ` John Stultz
2012-07-01 12:00 ` Jan Ceuleers [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-07-01 15:28 Prarit Bhargava
2012-07-01 16:56 ` Prarit Bhargava
2012-07-01 17:28 ` John Stultz
2012-07-02 10:16 ` Richard Cochran
2012-07-02 16:58 ` John Stultz
2012-07-02 20:08 ` Sytse Wielinga
2012-07-03 9:23 ` Richard Cochran
2012-07-03 12:05 ` Sytse Wielinga
2012-07-03 13:41 ` Richard Cochran
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=4FF03BDC.9070208@computer.org \
--to=jan.ceuleers@computer.org \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.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.