Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757087AbaDVQva (ORCPT ); Tue, 22 Apr 2014 12:51:30 -0400 Received: from www.linutronix.de ([62.245.132.108]:49523 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753194AbaDVQv2 (ORCPT ); Tue, 22 Apr 2014 12:51:28 -0400 Message-ID: <53569E05.8010600@linutronix.de> Date: Tue, 22 Apr 2014 18:51:17 +0200 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Steven Rostedt CC: Stanislav Meduna , "linux-rt-users@vger.kernel.org" , Linux ARM Kernel , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Peter Zijlstra Subject: Re: BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25 References: <534C3606.7010206@meduna.org> <534C731F.1050406@meduna.org> <534DADF1.6060608@meduna.org> <20140422115439.GA20669@linutronix.de> <20140422094657.5b6ca1e2@gandalf.local.home> In-Reply-To: <20140422094657.5b6ca1e2@gandalf.local.home> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/22/2014 03:46 PM, Steven Rostedt wrote: > [ added Peter ] > > On Tue, 22 Apr 2014 13:54:39 +0200 > Sebastian Andrzej Siewior 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/