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.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
