Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 603997 Details for
Bug 840948
livelock in leapsecond insertion [rhel-6.1.z]
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[patch]
RHEL PATCH 3/3
0003-RHEL6.1.z-PATCH-BZ-847364-3-3-timekeeping-Fix-leapse.patch (text/plain), 2.65 KB, created by
Prarit Bhargava
on 2012-08-13 13:01:25 UTC
(
hide
)
Description:
RHEL PATCH 3/3
Filename:
MIME Type:
Creator:
Prarit Bhargava
Created:
2012-08-13 13:01:25 UTC
Size:
2.65 KB
patch
obsolete
>From e986b2711efac8cfb3c344e79a6aff27d5449bb7 Mon Sep 17 00:00:00 2001 >From: Prarit Bhargava <prarit@redhat.com> >Date: Tue, 24 Jul 2012 10:23:22 -0400 >Subject: [PATCH 3/3] [RHEL6.1.z PATCH BZ 847364 3/3] timekeeping: Fix > leapsecond triggered load spike issue > >Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=847364 >Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=840948 > >commit 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51 >Author: John Stultz <johnstul@us.ibm.com> >Date: Tue Jul 10 18:43:20 2012 -0400 > > timekeeping: Fix leapsecond triggered load spike issue > > The timekeeping code misses an update of the hrtimer subsystem after a > leap second happened. Due to that timers based on CLOCK_REALTIME are > either expiring a second early or late depending on whether a leap > second has been inserted or deleted until an operation is initiated > which causes that update. Unless the update happens by some other > means this discrepancy between the timekeeping and the hrtimer data > stays forever and timers are expired either early or late. > > The reported immediate workaround - $ data -s "`date`" - is causing a > call to clock_was_set() which updates the hrtimer data structures. > See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix > > Add the missing clock_was_set() call to update_wall_time() in case of > a leap second event. The actual update is deferred to softirq context > as the necessary smp function call cannot be invoked from hard > interrupt context. > > Signed-off-by: John Stultz <johnstul@us.ibm.com> > Reported-by: Jan Engelhardt <jengelh@inai.de> > Reviewed-by: Ingo Molnar <mingo@kernel.org> > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> > Acked-by: Prarit Bhargava <prarit@redhat.com> > Cc: stable@vger.kernel.org > Link: http://lkml.kernel.org/r/1341960205-56738-3-git-send-email-johnstul@us.ibm.com > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > >In this minimal patchset I thought it was okay to call >clock_was_set_delayed() whenever there was an overflow. Of course, this >is incorrect, and clock_was_set_delayed() should only be called when we're >actually inserting a leap second. >--- > kernel/time/timekeeping.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c >index 6f50ef7..0cabb8c 100644 >--- a/kernel/time/timekeeping.c >+++ b/kernel/time/timekeeping.c >@@ -180,6 +180,7 @@ void timekeeping_leap_insert(int leapsecond) > wall_to_monotonic.tv_sec -= leapsecond; > update_vsyscall(&xtime, timekeeper.clock, timekeeper.mult); > write_sequnlock(&xtime_lock); >+ clock_was_set_delayed(); > } > > #ifdef CONFIG_GENERIC_TIME >-- >1.7.9.3 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 840948
:
603995
|
603996
| 603997