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 603993 Details for
Bug 840949
livelock in leapsecond insertion [rhel-6.2.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.2.z-PATCH-BZ-847365-3-3-timekeeping-Fix-leapse.patch (text/plain), 2.65 KB, created by
Prarit Bhargava
on 2012-08-13 12:55:11 UTC
(
hide
)
Description:
RHEL PATCH 3/3
Filename:
MIME Type:
Creator:
Prarit Bhargava
Created:
2012-08-13 12:55:11 UTC
Size:
2.65 KB
patch
obsolete
>From cbd54c469ea158e2ebbf3793766ce946909a2501 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.2.z PATCH BZ 847365 3/3] timekeeping: Fix > leapsecond triggered load spike issue > >Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=840949 >Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=847365 > >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 bae541b..ef67377 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 840949
:
603991
|
603992
| 603993