From: Thomas Gleixner <tglx@linutronix.de>
To: Gilles Carry <gilles.carry@bull.net>
Cc: linux-rt-users@vger.kernel.org, mingo@elte.hu,
tinytim@us.ibm.com, jean-pierre.dion@bull.net,
sebastien.dugue@bull.net
Subject: Re: [PATCH 1/2] [RT] hrtimers stuck in waitqueue
Date: Fri, 22 Aug 2008 16:39:21 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.1.10.0808221619080.3243@apollo.tec.linutronix.de> (raw)
In-Reply-To: <1219070552-30783-2-git-send-email-gilles.carry@bull.net>
On Mon, 18 Aug 2008, Gilles Carry wrote:
> This patch makes hrtimers initialized with hrtimer_init_sleeper
> to use another mode and then not be stuck in waitqueues when
> hrtimer_interrupt is very busy.
>
> The new mode is HRTIMER_CB_IRQSAFE_NO_RESTART_NO_SOFIRQ.
> The above-mentionned timers have been moved from
> HRTIMER_CB_IRQSAFE_NO_SOFTIRQ to
> HRTIMER_CB_IRQSAFE_NO_RESTART_NO_SOFIRQ.
>
> HRTIMER_CB_IRQSAFE_NO_RESTART_NO_SOFIRQ timers use a slightly different
> state machine from HRTIMER_CB_IRQSAFE_NO_SOFTIRQ's as when removing the
> timer, __run_hrtimer sets the status to INACTIVE _then_
> wakes up the thread. This way, an awakened thread cannot enter
> hrtimer_cancel before the timer's status has changed.
NAK. That solution is racy.
CPU 0 CPU 1
timer interrupt runs signal wakeup for task which sleeps
timer->state = INACTIVE;
-> Race window start
base->lock is dropped
hrtimer_cancel()
data structure on stack is destroyed
timer function called
data structure access --> POOOF
-> Race window end
base->lock is locked
The race is extremly narrow and requires an SMI or some other delay
(bus stall, cache miss ...) on CPU 0, but it exists.
Fix below.
Thanks,
tglx
---------------->
Subject: hrtimer: avoid waitqueue starvation
From: Thomas Gleixner <tglx@linutronix.de>
Date: Fri, 22 Aug 2008 16:27:13 +0200
Garry Gilles found that when a hrtimer callback runs in interrupt
context, then the woken up thread might end up on the timer wakequeue,
which might be blocked for a long time due to interrupts, higher
priority threads and no timers in the softirq list.
For timers which run their callback function in the hard irq context
we can safely spin and wait for the state to become inactive. The
waitqueue is only necessary for timers which run their callback
function in softirq context.
Debugged-by: Gilles Carry <gilles.carry@bull.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/hrtimer.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6.24.7/kernel/hrtimer.c
===================================================================
--- linux-2.6.24.7.orig/kernel/hrtimer.c
+++ linux-2.6.24.7/kernel/hrtimer.c
@@ -990,7 +990,14 @@ int hrtimer_cancel(struct hrtimer *timer
if (ret >= 0)
return ret;
- hrtimer_wait_for_timer(timer);
+ switch (timer->cb_mode) {
+ case HRTIMER_CB_IRQSAFE_NO_SOFTIRQ:
+ case HRTIMER_CB_IRQSAFE_NO_RESTART:
+ cpu_relax();
+ break;
+ default:
+ hrtimer_wait_for_timer(timer);
+ }
}
}
EXPORT_SYMBOL_GPL(hrtimer_cancel);
next prev parent reply other threads:[~2008-08-22 14:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-18 14:42 [PATCH 0/2][RT] hrtimers stuck in waitqueue Gilles Carry
2008-08-18 14:42 ` [PATCH 1/2] [RT] " Gilles Carry
2008-08-19 14:10 ` Gregory Haskins
[not found] ` <789E827C-DB3F-451E-BFFF-4210433029DF@free.fr>
2008-08-20 10:57 ` Gregory Haskins
2008-08-21 13:16 ` John Kacur
2008-08-22 6:11 ` Gilles Carry
2008-08-22 14:39 ` Thomas Gleixner [this message]
2008-08-25 13:09 ` Gilles Carry
2008-08-18 14:42 ` [PATCH 2/2] [RT] hrtimer __run_hrtimer code cleanup Gilles Carry
2008-08-20 21:48 ` John Kacur
2008-08-21 12:18 ` Gilles Carry
2008-08-21 13:03 ` John Kacur
2008-08-22 6:04 ` Gilles Carry
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=alpine.LFD.1.10.0808221619080.3243@apollo.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=gilles.carry@bull.net \
--cc=jean-pierre.dion@bull.net \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sebastien.dugue@bull.net \
--cc=tinytim@us.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).