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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 03 Mar 2007 10:02:20 +0100
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andres Salomon <dilinger@...ian.org>
Cc:	linux-kernel@...r.kernel.org, Marcelo Tosatti <marcelo@...ck.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH] dynticks: don't unlock spinlock twice

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



	

-
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/