There is a deadlock condition with RT spin_locks that may use trylock in
hardirq context. The main user of this is get_next_timer_interrupt, which
will deadlock if an IRQ preempts a timer wheel modification.
Errm. No.
Are you saying that spin_trylock will/should not be called from hardirq
context, or that it is not possible for spin_trylock to deadlock in the
situation I described? With PREEMPT_RT_FULL and NO_HZ_FULL on v3.10,
spin_trylock will definitely will be called from hardirq context. This
seems like a valid usage to me as well, as an optimization to prevent
disabling IRQs and preemption in code that holds the timer spinlock.
Even if this code did not cause a deadlock, is there a reason that
rt_mutex_slowtrylock is using raw_spin_lock instead of raw_spin_trylock?
I would think that we would want to ensure that any *trylock call
would return as fast as possible without spinning or blocking.
The cpu is in thread context and therefor not idle.
void tick_nohz_irq_exit(void)
{
if (!ts->inidle)
return;
....
}
So you are papering over the real issue:
Why is ts->inidle true, if the CPU is not in idle?
The code you cited is from pre-v3.10 (without NO_HZ_FULL changes). This
was changed in commit 5811d99 (nohz: Prepare to stop the tick on irq
exit). When ts->idle is false (as it was in my trace), this code now
calls tick_nohz_full_stop_tick(). This leads to the following trace:
do_raw_spin_lock
rt_spin_trylock
spin_do_trylock
get_next_timer_interrupt
tick_nohz_stop_sched_tick
tick_nohz_full_stop_tick
tick_nohz_irq_exit
irq_exit
I see two ways to fix this:
1) The way I did in the patch to ensure that spin_trylock never can spin
on any locks internally.
2) Converting the timer base lock to a raw_spinlock_t so that it
actually disables hardirqs in lock_timer_base(). I don't think this
would be a good idea though.
Thanks,
-Matt
--
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