From: Gilles Carry <Gilles.Carry@bull.net>
To: Thomas Gleixner <tglx@linutronix.de>
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: Mon, 25 Aug 2008 15:09:04 +0200 [thread overview]
Message-ID: <48B2AEF0.4020809@bull.net> (raw)
In-Reply-To: <alpine.LFD.1.10.0808221619080.3243@apollo.tec.linutronix.de>
Thomas Gleixner wrote:
> 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
>
Ooops! I did not think of that.
A so narrow window that my tests did not reveal.
Thank-you Thomas.
Gilles.
next prev parent reply other threads:[~2008-08-25 13:09 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
2008-08-25 13:09 ` Gilles Carry [this message]
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=48B2AEF0.4020809@bull.net \
--to=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=tglx@linutronix.de \
--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 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.