[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 02 Mar 2007 21:52:40 -0500
From: Andres Salomon <dilinger@...ian.org>
To: linux-kernel@...r.kernel.org
CC: Marcelo Tosatti <marcelo@...ck.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...l.org>
Subject: [PATCH] dynticks: don't unlock spinlock twice
During boot with dynticks enabled, we would sometimes get:
[ 35.271900] Switched to high resolution mode on CPU 0
[ 35.304468] BUG: spinlock already unlocked on CPU#0, swapper/1
[ 35.338099] lock: c06428a0, .magic: dead4ead, .owner: <none>/-1,
.owner_cpu:
-1
[ 35.373597] [<c04d7cf0>] _raw_spin_unlock+0x28/0x67
[ 35.406647] [<c05ba279>] _spin_unlock+0x5/0x23
[ 35.439369] [<c04255f7>] tick_sched_timer+0x4e/0xa7
[ 35.472388] [<c04255a9>] tick_sched_timer+0x0/0xa7
[ 35.504833] [<c0422528>] hrtimer_run_queues+0x199/0x1ec
[ 35.537617] [<c0416b72>] run_timer_softirq+0x12/0x166
[ 35.570019] [<c04144d9>] __do_softirq+0x40/0x85
[ 35.601542] [<c0405494>] do_softirq+0x53/0xa9
...
This appears to be caused by run_hrtimer_queue() (called by
hrtimer_run_queues) calling spin_unlock_irq(&cpu_base->lock) before
calling timer->function(timer). The callback function
(tick_sched_timer) expects cpu_base->lock to be held when it is called,
and attempts to unlock it. Since it doesn't seem like anything within
tick_sched_timer really needs to hold the lock (afaict), the attached
patch simply removes the lock handling from tick_sched_timer. Things
called by tick_sched_timer may grab the base->lock, but that's fine (and
their responsibility). Let me know if there's some reason why the lock
should be held, and I can rework this.
Signed-off-by: Andres Salomon <dilinger@...ian.org>
View attachment "x" of type "text/plain" (1416 bytes)
Powered by blists - more mailing lists