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 09:46:57 -0400 [thread overview]
Message-ID: <20140422094657.5b6ca1e2@gandalf.local.home> (raw)
In-Reply-To: <20140422115439.GA20669@linutronix.de>
[ 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.
-- Steve
WARNING: multiple messages have this Message-ID (diff)
From: rostedt@goodmis.org (Steven Rostedt)
To: linux-arm-kernel@lists.infradead.org
Subject: BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25
Date: Tue, 22 Apr 2014 09:46:57 -0400 [thread overview]
Message-ID: <20140422094657.5b6ca1e2@gandalf.local.home> (raw)
In-Reply-To: <20140422115439.GA20669@linutronix.de>
[ 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.
-- Steve
next prev parent reply other threads:[~2014-04-22 13:47 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 19:24 BUG: spinlock trylock failure on UP, i.MX28 3.12.15-rt25 Stanislav Meduna
2014-04-14 23:45 ` Stanislav Meduna
2014-04-14 23:45 ` Stanislav Meduna
2014-04-15 22:08 ` 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 16:29 ` Stanislav Meduna
2014-04-17 22:55 ` Stanislav Meduna
2014-04-17 22:55 ` Stanislav Meduna
2014-04-17 23:10 ` jordan
2014-04-17 23:10 ` jordan
2014-04-18 1:15 ` jordan
2014-04-18 1:15 ` jordan
2014-04-18 1:15 ` jordan
2014-04-18 14:45 ` Stanislav Meduna
2014-04-18 14:45 ` Stanislav Meduna
2014-04-18 15:09 ` jordan
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 11:54 ` Sebastian Andrzej Siewior
2014-04-22 13:46 ` Steven Rostedt [this message]
2014-04-22 13:46 ` Steven Rostedt
2014-04-22 14:09 ` Peter Zijlstra
2014-04-22 14:09 ` Peter Zijlstra
2014-04-23 8:10 ` Sebastian Andrzej Siewior
2014-04-23 8:10 ` Sebastian Andrzej Siewior
2014-04-23 8:50 ` Peter Zijlstra
2014-04-23 8:50 ` Peter Zijlstra
2014-04-22 16:51 ` Sebastian Andrzej Siewior
2014-04-22 16:51 ` Sebastian Andrzej Siewior
2014-04-22 17:48 ` Steven Rostedt
2014-04-22 17:48 ` Steven Rostedt
2014-04-22 18:16 ` Steven Rostedt
2014-04-22 18:16 ` Steven Rostedt
2014-04-23 7:14 ` Sebastian Andrzej Siewior
2014-04-23 7:14 ` Sebastian Andrzej Siewior
2014-04-23 8:49 ` Peter Zijlstra
2014-04-23 8:49 ` Peter Zijlstra
2014-04-23 12:15 ` Steven Rostedt
2014-04-23 12:15 ` Steven Rostedt
2014-05-02 18:38 ` Sebastian Andrzej Siewior
2014-05-02 18:38 ` Sebastian Andrzej Siewior
2014-05-02 19:01 ` Thomas Gleixner
2014-05-02 19:01 ` Thomas Gleixner
2014-05-02 19:36 ` Thomas Gleixner
2014-05-02 19:36 ` Thomas Gleixner
2014-05-02 19:37 ` Sebastian Andrzej Siewior
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=20140422094657.5b6ca1e2@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.