Re: [PATCH] dynticks: don't unlock spinlock twice

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, 2007-03-02 at 21:52 -0500, Andres Salomon wrote:
> 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.

The BUG is somewhere else. the tick timer should never be seen in
hrtimer_run_queues. The tick timer is operated solely from the timer
interrupt. 

The question is, how the tick timer gets enqueued in the softirq queue.
Can you isolate the codepath, where this happens ?

	tglx