From: Steven Rostedt <rostedt@goodmis.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Stanislav Meduna <stano@meduna.org>,
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25
Date: Tue, 22 Apr 2014 13:48:02 -0400 [thread overview]
Message-ID: <20140422134802.73fc1fa4@gandalf.local.home> (raw)
In-Reply-To: <53569E05.8010600@linutronix.de>
On Tue, 22 Apr 2014 18:51:17 +0200
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 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@linutronix.de> 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.
There's nothing wrong with taking locks with irqs enabled and disabled.
It's only wrong if that lock (or a lock that is held when the lock is
taken) is also taking in interrupt *context*.
>
> 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.
I need to take a deeper look into the actual code. But as trylocks on
UP are nops (always succeed), and if it expects to be able to do
something in a critical section that is protected by spinlocks (again
nops on UP), this would be broken for UP.
-- Steve
next prev parent reply other threads:[~2014-04-22 17:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <534C3606.7010206@meduna.org>
2014-04-14 23:45 ` BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25 Stanislav Meduna
2014-04-15 22:08 ` Stanislav Meduna
2014-04-17 16:29 ` BUG: spinlock trylock failure on UP - reverting timer patches helps Stanislav Meduna
2014-04-17 22:55 ` Stanislav Meduna
2014-04-17 23:10 ` jordan
2014-04-18 1:15 ` jordan
2014-04-18 14:45 ` Stanislav Meduna
2014-04-18 15:09 ` jordan
2014-04-22 11:54 ` BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25 Sebastian Andrzej Siewior
2014-04-22 13:46 ` Steven Rostedt
2014-04-22 14:09 ` Peter Zijlstra
2014-04-23 8:10 ` Sebastian Andrzej Siewior
2014-04-23 8:50 ` Peter Zijlstra
2014-04-22 16:51 ` Sebastian Andrzej Siewior
2014-04-22 17:48 ` Steven Rostedt [this message]
2014-04-22 18:16 ` Steven Rostedt
2014-04-23 7:14 ` Sebastian Andrzej Siewior
2014-04-23 8:49 ` Peter Zijlstra
2014-04-23 12:15 ` Steven Rostedt
2014-05-02 18:38 ` Sebastian Andrzej Siewior
2014-05-02 19:01 ` Thomas Gleixner
2014-05-02 19:36 ` Thomas Gleixner
2014-05-02 19:37 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140422134802.73fc1fa4@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=bigeasy@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=stano@meduna.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).