Re: [PATCH RT] rtmutex: fix deadlock in spin_trylock

[Matt Cowell <matt.cowell@nsn.com>]

>> 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