From: John Stultz <johnstul@us.ibm.com>
To: John Stultz <johnstul@us.ibm.com>
Cc: stable@vger.kernel.org, Prarit Bhargava <prarit@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/11] 3.2-stable: Fix for leapsecond caused hrtimer/futex issue
Date: Tue, 17 Jul 2012 00:10:17 -0700 [thread overview]
Message-ID: <50050FD9.3070403@us.ibm.com> (raw)
In-Reply-To: <1342508724-14527-1-git-send-email-johnstul@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
On 07/17/2012 12:05 AM, John Stultz wrote:
> 1) Deadlock leapsecond issue that a few reports described.
>
> I spent some time over the weekend trying to find a way to reproduce
> the hard-hang issue some folks were reporting after the leapsecond.
> Initially I didn't think the 6b43ae8a619d17 leap-second hrimter livelock
> patch needed to be backported since, I assumed it required the ntp_lock
> split for it to be triggered, but looking again I found that the same
> issue could occur prior to splitting out the ntp_lock. So I've backported
> that fix (and its follow-on fixups) as well as created a test case
> to reproduce the hard-hang deadlock.
Attached is the test case I used to reproduce and test the solution to
the hard-hang deadlock.
WARNING: THIS TEST WILL LIKELY HARD LOCK YOUR BOX IN IRQ CONTEXT!
YOU MAY LOSE DATA! RUN AT YOUR OWN RISK!
thanks
-john
[-- Attachment #2: leapcrash.c --]
[-- Type: text/x-csrc, Size: 1928 bytes --]
/* Demo leapsecond deadlock
* by: john stultz (johnstul@us.ibm.com)
* (C) Copyright IBM 2012
* Licensed under the GPL
*
* This test demonstrates leapsecond deadlock that is possibe
* on kernels from 2.6.26 to 3.3.
*
* WARNING: THIS WILL LIKELY HARDHANG SYSTEMS AND MAY LOSE DATA
* RUN AT YOUR OWN RISK!
* To build:
* $ gcc leapcrash.c -o leapcrash -lrt
*/
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>
#include <sys/timex.h>
#include <string.h>
#include <signal.h>
/* clear NTP time_status & time_state */
void clear_time_state(void)
{
struct timex tx;
int ret;
/*
* XXX - The fact we have to call this twice seems
* to point to a slight issue in the kernel's ntp state
* managment. Needs to be investigated further.
*/
tx.modes = ADJ_STATUS;
tx.status = STA_PLL;
ret = adjtimex(&tx);
tx.modes = ADJ_STATUS;
tx.status = 0;
ret = adjtimex(&tx);
}
/* Make sure we cleanup on ctrl-c */
void handler(int unused)
{
clear_time_state();
exit(0);
}
int main(void)
{
struct timex tx;
struct timespec ts;
time_t next_leap;
int count =0;
setbuf(stdout, NULL);
signal(SIGINT, handler);
signal(SIGKILL, handler);
printf("This runs continuously. Press ctrl-c to stop\n");
clear_time_state();
/* Get the current time */
clock_gettime(CLOCK_REALTIME, &ts);
/* Calculate the next possible leap second 23:59:60 GMT */
next_leap = ts.tv_sec;
next_leap += 86400 - (next_leap % 86400);
while (1) {
struct timeval tv;
/* set the time to 2 seconds before the leap */
tv.tv_sec = next_leap - 2;
tv.tv_usec = 0;
settimeofday(&tv, NULL);
adjtimex(&tx);
/* hammer on adjtime w/ STA_INS */
while (tx.time.tv_sec < next_leap + 1) {
/* Set the leap second insert flag */
tx.modes = ADJ_STATUS;
tx.status = STA_INS;
adjtimex(&tx);
}
clear_time_state();
printf(".");
}
return 0;
}
next prev parent reply other threads:[~2012-07-17 7:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-17 7:05 [PATCH 00/11] 3.2-stable: Fix for leapsecond caused hrtimer/futex issue John Stultz
2012-07-17 7:05 ` [PATCH 01/11] 3.2.x: ntp: Fix leap-second hrtimer livelock John Stultz
2012-07-17 7:05 ` [PATCH 02/11] 3.2.x: ntp: Correct TAI offset during leap second John Stultz
2012-07-17 7:05 ` [PATCH 03/11] 3.2.x: timekeeping: Fix CLOCK_MONOTONIC inconsistency during leapsecond John Stultz
2012-07-17 7:05 ` [PATCH 04/11] 3.2.x: time: Move common updates to a function John Stultz
2012-07-17 7:05 ` [PATCH 05/11] 3.2.x: hrtimer: Provide clock_was_set_delayed() John Stultz
2012-07-17 7:05 ` [PATCH 06/11] 3.2.x: timekeeping: Fix leapsecond triggered load spike issue John Stultz
2012-07-17 7:05 ` [PATCH 07/11] 3.2.x: timekeeping: Maintain ktime_t based offsets for hrtimers John Stultz
2012-07-17 7:05 ` [PATCH 08/11] 3.2.x: hrtimers: Move lock held region in hrtimer_interrupt() John Stultz
2012-07-17 7:05 ` [PATCH 09/11] 3.2.x: timekeeping: Provide hrtimer update function John Stultz
2012-07-17 7:05 ` [PATCH 10/11] 3.2.x: hrtimer: Update hrtimer base offsets each hrtimer_interrupt John Stultz
2012-07-17 7:05 ` [PATCH 11/11] 3.2.x: timekeeping: Add missing update call in timekeeping_resume() John Stultz
2012-07-17 7:10 ` John Stultz [this message]
2012-07-19 20:48 ` [PATCH 00/11] 3.2-stable: Fix for leapsecond caused hrtimer/futex issue Christoph Biedl
2012-07-23 19:51 ` John Stultz
2012-07-24 2:37 ` Ben Hutchings
2012-07-22 18:50 ` Ben Hutchings
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=50050FD9.3070403@us.ibm.com \
--to=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=prarit@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox