[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060906100507.GA12799@elte.hu>
Date: Wed, 6 Sep 2006 12:05:07 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Heiko Carstens <heiko.carstens@...ibm.com>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
Arjan van de Ven <arjan@...radead.org>,
Daniel Walker <dwalker@...sta.com>,
Hua Zhong <hzhong@...il.com>
Subject: Re: lockdep oddity
* Heiko Carstens <heiko.carstens@...ibm.com> wrote:
> That seems to be code that isn't upstream. 2.6.18-rc5-mm1 as well as
> Linus' current git tree have this:
>
> /*
> * If lockdep is enabled then we use the non-preemption spin-ops
> * even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
> * not re-enabled during lock-acquire (which the preempt-spin-ops do):
> */
> #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
> defined(CONFIG_PROVE_LOCKING)
>
> And yes, using CONFIG_DEBUG_LOCK_ALLOC instead of CONFIG_PROVE_LOCKING
> fixes this for me :)
indeed, this is a very recent fix from Jarek Poplawski - not yet in
Linus' tree but already in Andrew's.
Ingo
---------->
From: Jarek Poplawski <jarkao2@...pl>
With
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
spin_unlock_irqrestore() goes through lockdep but spin_lock_irqsave() doesn't.
Apparently, bad things happen.
Acked-by: Ingo Molnar <mingo@...e.hu>
Signed-off-by: Andrew Morton <akpm@...l.org>
---
kernel/spinlock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN kernel/spinlock.c~lockdep-ifdef-fix kernel/spinlock.c
--- a/kernel/spinlock.c~lockdep-ifdef-fix
+++ a/kernel/spinlock.c
@@ -72,7 +72,7 @@ EXPORT_SYMBOL(_write_trylock);
* not re-enabled during lock-acquire (which the preempt-spin-ops do):
*/
#if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
- defined(CONFIG_PROVE_LOCKING)
+ defined(CONFIG_DEBUG_LOCK_ALLOC)
void __lockfunc _read_lock(rwlock_t *lock)
{
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists