public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] dynticks: don't unlock spinlock twice
@ 2007-03-03  2:52 Andres Salomon
  2007-03-03  9:02 ` Thomas Gleixner
  0 siblings, 1 reply; 11+ messages in thread
From: Andres Salomon @ 2007-03-03  2:52 UTC (permalink / raw)
  To: linux-kernel; +Cc: Marcelo Tosatti, Thomas Gleixner, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

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@debian.org>

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1415 bytes --]

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 51556b9..b43bccb 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -422,13 +422,12 @@ static inline void tick_nohz_switch_to_nohz(void) { }
 #ifdef CONFIG_HIGH_RES_TIMERS
 /*
  * We rearm the timer until we get disabled by the idle code
- * Called with interrupts disabled and timer->base->cpu_base->lock held.
+ * Called with interrupts disabled and timer->base->cpu_base->lock *not* held.
  */
 static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
 {
 	struct tick_sched *ts =
 		container_of(timer, struct tick_sched, sched_timer);
-	struct hrtimer_cpu_base *base = timer->base->cpu_base;
 	struct pt_regs *regs = get_irq_regs();
 	ktime_t now = ktime_get();
 
@@ -454,13 +453,12 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
 		}
 		/*
 		 * update_process_times() might take tasklist_lock, hence
-		 * drop the base lock. sched-tick hrtimers are per-CPU and
-		 * never accessible by userspace APIs, so this is safe to do.
+		 * we don't attempt to grab the base lock here.
+		 * sched-tick hrtimers are per-CPU and never accessible by
+		 * userspace APIs, so this is safe to do.
 		 */
-		spin_unlock(&base->lock);
 		update_process_times(user_mode(regs));
 		profile_tick(CPU_PROFILING);
-		spin_lock(&base->lock);
 	}
 
 	/* Do not restart, when we are in the idle loop */

^ permalink raw reply related	[flat|nested] 11+ messages in thread
* [5/6] 2.6.21-rc2: known regressions
@ 2007-03-05  1:50 Adrian Bunk
  2007-03-05 23:43 ` Thomas Gleixner
  0 siblings, 1 reply; 11+ messages in thread
From: Adrian Bunk @ 2007-03-05  1:50 UTC (permalink / raw)
  To: Linus Torvalds, Andrew Morton
  Cc: Linux Kernel Mailing List, Michal Piotrowski, Thomas Gleixner,
	Emil Karlson, Michael S. Tsirkin, Ingo Molnar, Soeren Sonnenburg,
	Daniel Walker

This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : soft lockup detected on CPU#0
References : http://lkml.org/lkml/2007/3/3/152
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : unknown


Subject    : dynticks makes ksoftirqd1 use unreasonable amount of cpu time
References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
Submitter  : Emil Karlson <jkarlson@cc.hut.fi>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
             (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : macbook pro suspend to ram broken  (clockevents)
References : http://lkml.org/lkml/2007/3/4/110
Submitter  : Soeren Sonnenburg <kernel@nn7.de>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Status     : unknown


Subject    : i386: no boot with nmi_watchdog=1  (clockevents)
References : http://lkml.org/lkml/2007/2/21/208
Submitter  : Daniel Walker <dwalker@mvista.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-03-06 17:46 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-03  2:52 [PATCH] dynticks: don't unlock spinlock twice Andres Salomon
2007-03-03  9:02 ` Thomas Gleixner
2007-03-04 11:14   ` Andres Salomon
2007-03-04 13:09     ` [PATCH] highres: Do not run the TIMER_SOFTIRQ after switching to highres mode Thomas Gleixner
2007-03-04 13:12       ` Andres Salomon
2007-03-04 13:23         ` Thomas Gleixner
2007-03-05  7:25         ` Ingo Molnar
2007-03-05  7:50           ` Andres Salomon
2007-03-05  7:52             ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2007-03-05  1:50 [5/6] 2.6.21-rc2: known regressions Adrian Bunk
2007-03-05 23:43 ` Thomas Gleixner
2007-03-05 23:45   ` Linus Torvalds
2007-03-06  0:38     ` Linus Torvalds
2007-03-06  1:02       ` Thomas Gleixner
2007-03-06  1:31         ` Linus Torvalds
2007-03-06  2:18           ` Linus Torvalds
2007-03-06 10:33             ` Michael S. Tsirkin
2007-03-06 10:37               ` Ingo Molnar
2007-03-06 10:46                 ` Michael S. Tsirkin
2007-03-06 11:32                   ` Ingo Molnar
2007-03-06 16:44                     ` Linus Torvalds
2007-03-06 17:29                       ` [PATCH] highres: do not run the TIMER_SOFTIRQ after switching to highres mode Thomas Gleixner
2007-03-06 17:41                         ` Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox