Re: BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25

[Sebastian Andrzej Siewior]

On 04/22/2014 03:46 PM, Steven Rostedt wrote:
> [ added Peter ]
> 
> On Tue, 22 Apr 2014 13:54:39 +0200
> Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:
>  
>> this is, erm, harmless. We grab the timer lock via trylock in hardirq
>> context. If the lock is already taken then we fail to get it we go for
>> plan B. According to lockdep a trylock should not fail on UP. This is
>> true in general except for this timer case. I was thinking abour
>> disabling this lockdep checkâ
> 
> trylock not failing on UP, can that be an issue? I mean, if a hardirq
> does a trylock to see if it can grab a lock that is not protected by
> disabling irqs, and will go to plan B if it fails, on UP, it will
> always get it.  But the issue is still there. That would mean that a
> hardirq could have preempted a critical section and doing a trylock
> here would succeed when it really should have failed.

If you take a lock with irqs enabled and disabled then lockdep should
complain about it.

This is the ->wait_lock of the timer base lock. This (sleeping) lock is
usually taken with interrupts enabled. Except here, in the timer
callback, we check if the lock is available or not. And this lock may
be a) taken (and the ->wait_lock unlocked) or b) in process to be taken
but the caller only succeeded to acquire the ->wait_lock before the
interrupt occurred. This is the case here and we can't acquire the
->wait_lock a second time the check if the lock is really taken. But
since the wait_lock is occupied it is likely that the lock itself is
occupied as well.

> 
> -- Steve

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/