public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
	lenb@kernel.org, rjw@rjwysocki.net,
	Eliezer Tamir <eliezer.tamir@linux.intel.com>,
	Chris Leech <christopher.leech@intel.com>,
	David Miller <davem@davemloft.net>,
	rui.zhang@intel.com, Mike Galbraith <bitbucket@online.de>,
	Ingo Molnar <mingo@kernel.org>,
	hpa@zytor.com, Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 0/7] Cure some vaux idle wrackage
Date: Wed, 20 Nov 2013 18:24:24 +0100	[thread overview]
Message-ID: <20131120172424.GV16796@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <20131120091921.2da67ff3@ultegra>

On Wed, Nov 20, 2013 at 09:19:21AM -0800, Jacob Pan wrote:
> Hi Peter,
> I cannot cleanly apply the patch set on upstream kernel. Failed on
> Subject: [PATCH 4/7] preempt, locking: Rework local_bh_{dis,en}able()
> 
> Can you tell me which commit id should I do git am?

Oh, I wrote them against tip/master. Although I don't suppose there's
much in tip/master that's not (yet) in Linus' tree, so I suppose the
conflict should be an easy one.

I suppose the patch giving you grief is the one below.

---
commit f1a83e652bedef88d6d77d3dc58250e08e7062bd
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Nov 19 16:42:47 2013 +0100

    lockdep: Correctly annotate hardirq context in irq_exit()
    
    There was a reported deadlock on -rt which lockdep didn't report.
    
    It turns out that in irq_exit() we tell lockdep that the hardirq
    context ends and then do all kinds of locking afterwards.
    
    To fix it, move trace_hardirq_exit() to the very end of irq_exit(), this
    ensures all locking in tick_irq_exit() and rcu_irq_exit() are properly
    recorded as happening from hardirq context.
    
    This however leads to the 'fun' little problem of running softirqs
    while in hardirq context. To cure this make the softirq code a little
    more complex (in the CONFIG_TRACE_IRQFLAGS case).
    
    Due to stack swizzling arch dependent trickery we cannot pass an
    argument to __do_softirq() to tell it if it was done from hardirq
    context or not; so use a side-band argument.
    
    When we do __do_softirq() from hardirq context, 'atomically' flip to
    softirq context and back, so that no locking goes without being in
    either hard- or soft-irq context.
    
    I didn't find any new problems in mainline using this patch, but it
    did show the -rt problem.
    
    Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/n/tip-dgwc5cdksbn0jk09vbmcc9sa@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

diff --git a/kernel/softirq.c b/kernel/softirq.c
index b24988353458..eb0acf44b063 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -213,14 +213,52 @@ EXPORT_SYMBOL(local_bh_enable_ip);
 #define MAX_SOFTIRQ_TIME  msecs_to_jiffies(2)
 #define MAX_SOFTIRQ_RESTART 10
 
+#ifdef CONFIG_TRACE_IRQFLAGS
+/*
+ * Convoluted means of passing __do_softirq() a message through the various
+ * architecture execute_on_stack() bits.
+ *
+ * When we run softirqs from irq_exit() and thus on the hardirq stack we need
+ * to keep the lockdep irq context tracking as tight as possible in order to
+ * not miss-qualify lock contexts and miss possible deadlocks.
+ */
+static DEFINE_PER_CPU(int, softirq_from_hardirq);
+
+static inline void lockdep_softirq_from_hardirq(void)
+{
+	this_cpu_write(softirq_from_hardirq, 1);
+}
+
+static inline void lockdep_softirq_start(void)
+{
+	if (this_cpu_read(softirq_from_hardirq))
+		trace_hardirq_exit();
+	lockdep_softirq_enter();
+}
+
+static inline void lockdep_softirq_end(void)
+{
+	lockdep_softirq_exit();
+	if (this_cpu_read(softirq_from_hardirq)) {
+		this_cpu_write(softirq_from_hardirq, 0);
+		trace_hardirq_enter();
+	}
+}
+
+#else
+static inline void lockdep_softirq_from_hardirq(void) { }
+static inline void lockdep_softirq_start(void) { }
+static inline void lockdep_softirq_end(void) { }
+#endif
+
 asmlinkage void __do_softirq(void)
 {
-	struct softirq_action *h;
-	__u32 pending;
 	unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
-	int cpu;
 	unsigned long old_flags = current->flags;
 	int max_restart = MAX_SOFTIRQ_RESTART;
+	struct softirq_action *h;
+	__u32 pending;
+	int cpu;
 
 	/*
 	 * Mask out PF_MEMALLOC s current task context is borrowed for the
@@ -233,7 +271,7 @@ asmlinkage void __do_softirq(void)
 	account_irq_enter_time(current);
 
 	__local_bh_disable(_RET_IP_, SOFTIRQ_OFFSET);
-	lockdep_softirq_enter();
+	lockdep_softirq_start();
 
 	cpu = smp_processor_id();
 restart:
@@ -280,16 +318,13 @@ asmlinkage void __do_softirq(void)
 		wakeup_softirqd();
 	}
 
-	lockdep_softirq_exit();
-
+	lockdep_softirq_end();
 	account_irq_exit_time(current);
 	__local_bh_enable(SOFTIRQ_OFFSET);
 	WARN_ON_ONCE(in_interrupt());
 	tsk_restore_flags(current, old_flags, PF_MEMALLOC);
 }
 
-
-
 asmlinkage void do_softirq(void)
 {
 	__u32 pending;
@@ -332,6 +367,7 @@ void irq_enter(void)
 static inline void invoke_softirq(void)
 {
 	if (!force_irqthreads) {
+		lockdep_softirq_from_hardirq();
 #ifdef CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK
 		/*
 		 * We can safely execute softirq on the current stack if
@@ -377,13 +413,13 @@ void irq_exit(void)
 #endif
 
 	account_irq_exit_time(current);
-	trace_hardirq_exit();
 	preempt_count_sub(HARDIRQ_OFFSET);
 	if (!in_interrupt() && local_softirq_pending())
 		invoke_softirq();
 
 	tick_irq_exit();
 	rcu_irq_exit();
+	trace_hardirq_exit(); /* must be last! */
 }
 
 /*

      reply	other threads:[~2013-11-20 17:24 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-20 16:04 [PATCH 0/7] Cure some vaux idle wrackage Peter Zijlstra
2013-11-20 16:04 ` [PATCH 1/7] x86, acpi, idle: Restructure the mwait idle routines Peter Zijlstra
2013-11-20 16:04 ` [PATCH 2/7] sched, preempt: Fixup missed PREEMPT_NEED_RESCHED folding Peter Zijlstra
2013-11-21  8:25   ` Peter Zijlstra
2013-11-20 16:04 ` [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations Peter Zijlstra
2013-11-20 16:40   ` Arjan van de Ven
2013-11-20 16:59     ` Peter Zijlstra
2013-11-20 17:23     ` Thomas Gleixner
2013-11-20 17:23       ` Arjan van de Ven
2013-11-20 17:55         ` Thomas Gleixner
2013-11-20 18:21           ` Arjan van de Ven
2013-11-20 19:38             ` Thomas Gleixner
2013-11-20 22:08               ` Jacob Pan
2013-11-21  0:54   ` Jacob Pan
2013-11-21  8:21     ` Peter Zijlstra
2013-11-21 16:07       ` Paul E. McKenney
2013-11-21 16:21         ` Arjan van de Ven
2013-11-21 19:19           ` Paul E. McKenney
2013-11-21 19:45             ` Arjan van de Ven
2013-11-21 20:07               ` Paul E. McKenney
2013-11-22  0:10                 ` Jacob Pan
2013-11-22  4:20                   ` Paul E. McKenney
2013-11-22 11:33                     ` Peter Zijlstra
2013-11-22 17:17                       ` Paul E. McKenney
2013-11-21 16:29         ` Peter Zijlstra
2013-11-21 17:27           ` Paul E. McKenney
2013-11-20 16:04 ` [PATCH 4/7] preempt, locking: Rework local_bh_{dis,en}able() Peter Zijlstra
2013-11-20 16:04 ` [PATCH 5/7] locking: Optimize lock_bh functions Peter Zijlstra
2013-11-20 16:04 ` [PATCH 6/7] sched: Clean up preempt_enable_no_resched() abuse Peter Zijlstra
2013-11-20 18:02   ` Eliezer Tamir
2013-11-20 18:15     ` Peter Zijlstra
2013-11-20 20:14       ` Eliezer Tamir
2013-11-21 10:10     ` Peter Zijlstra
2013-11-21 13:26       ` Eliezer Tamir
2013-11-21 13:39         ` Peter Zijlstra
2013-11-22  6:56           ` Eliezer Tamir
2013-11-22 11:30             ` Peter Zijlstra
2013-11-26  7:15               ` Eliezer Tamir
2013-11-26 10:51                 ` Thomas Gleixner
2013-11-20 16:04 ` [PATCH 7/7] preempt: Take away preempt_enable_no_resched() from modules Peter Zijlstra
2013-11-20 18:54   ` Jacob Pan
2013-11-20 19:00     ` Peter Zijlstra
2013-11-20 19:18     ` Peter Zijlstra
2013-11-20 19:29       ` Jacob Pan
2013-11-20 16:34 ` [PATCH 0/7] Cure some vaux idle wrackage Peter Zijlstra
2013-11-20 17:19   ` Jacob Pan
2013-11-20 17:24     ` Peter Zijlstra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131120172424.GV16796@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=arjan@linux.intel.com \
    --cc=bitbucket@online.de \
    --cc=christopher.leech@intel.com \
    --cc=davem@davemloft.net \
    --cc=eliezer.tamir@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rui.zhang@intel.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox