core/printk changes for v3.1

Linus,

Please pull the latest core-printk-for-linus git tree from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core-printk-for-linus

( These are just the tested-safe commits - the ones that were causing problems are not included. )

 Thanks,

       Ingo

------------------>
Peter Zijlstra (3):

     [...]

     lockdep: Fix trace_[soft,hard]irqs_[on,off]() recursion

Quoted 4 lines

Peter Zijlstra (3):
[...]
lockdep: Fix trace_[soft,hard]irqs_[on,off]() recursion

This commit is triggering:

WARNING: at /src/linux/linux/kernel/lockdep.c:2529

Quoted 7 lines

Quoted 4 lines

Peter Zijlstra (3):
[...]
lockdep: Fix trace_[soft,hard]irqs_[on,off]() recursion

This commit is triggering:

WARNING: at /src/linux/linux/kernel/lockdep.c:2529

Not actually having reproduced the problem, does the below cure things?

---
Subject: lockdep: Fix trace_hardirqs_on_caller()
From: Peter Zijlstra <[email protected]>
Date: Tue Jul 26 13:13:44 CEST 2011

Commit dd4e5d3ac4a ("lockdep: Fix trace_[soft,hard]irqs_[on,off]() recursion") made a bit of a mess of the various checks and error conditions.

In particular it moved the check for !irqs_disabled() before the spurious enable test, resulting in some warnings.

Reported-by Arnaud Lacombe <[email protected]>

Reported-by Dave Jones <[email protected]>

Reported-by Sergey Senozhatsky <[email protected]>

Signed-off-by Peter Zijlstra <[email protected]>

---
 kernel/lockdep.c |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

Index: linux-2.6/kernel/lockdep.c
===================================================================

kernel/lockdep.c +16 -14

@@ -2485,23 +2485,9 @@ static void __trace_hardirqs_on_caller(u
 {
 	struct task_struct *curr = current;
 
-	if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
-		return;
-
-	if (unlikely(curr->hardirqs_enabled)) {
-		/*
-		 * Neither irq nor preemption are disabled here
-		 * so this is racy by nature but losing one hit
-		 * in a stat is not a big deal.
-		 */
-		__debug_atomic_inc(redundant_hardirqs_on);
-		return;
-	}
 	/* we'll do an OFF -> ON transition: */
 	curr->hardirqs_enabled = 1;
 
-	if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
-		return;
 	/*
 	 * We are going to turn hardirqs on, so set the
 	 * usage bit for all held locks:

@@ -2529,9 +2515,25 @@ void trace_hardirqs_on_caller(unsigned l
 	if (unlikely(!debug_locks || current->lockdep_recursion))
 		return;
 
+	if (unlikely(current->hardirqs_enabled)) {
+		/*
+		 * Neither irq nor preemption are disabled here
+		 * so this is racy by nature but losing one hit
+		 * in a stat is not a big deal.
+		 */
+		__debug_atomic_inc(redundant_hardirqs_on);
+		return;
+	}
+
 	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
 		return;
 
+	if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
+		return;
+
+	if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
+		return;
+
 	current->lockdep_recursion = 1;
 	__trace_hardirqs_on_caller(ip);
 	current->lockdep_recursion = 0;

Quoted 1 line

WARNING: at /src/linux/linux/kernel/lockdep.c:2529

Not actually having reproduced the problem, does the below cure things?

---
Subject: lockdep: Fix trace_hardirqs_on_caller()
From: Peter Zijlstra <[email protected]>
Date: Tue Jul 26 13:13:44 CEST 2011

Commit dd4e5d3ac4a ("lockdep: Fix trace_[soft,hard]irqs_[on,off]() recursion") made a bit of a mess of the various checks and error conditions.

In particular it moved the check for !irqs_disabled() before the spurious enable test, resulting in some warnings.

Reported-by Arnaud Lacombe <[email protected]>

Reported-by Dave Jones <[email protected]>

Reported-by Sergey Senozhatsky <[email protected]>

Signed-off-by Peter Zijlstra <[email protected]>

---
 kernel/lockdep.c |   30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

Index: linux-2.6/kernel/lockdep.c
===================================================================

kernel/lockdep.c +16 -14

@@ -2485,23 +2485,9 @@ static void __trace_hardirqs_on_caller(u
 {
 	struct task_struct *curr = current;
 
-	if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
-		return;
-
-	if (unlikely(curr->hardirqs_enabled)) {
-		/*
-		 * Neither irq nor preemption are disabled here
-		 * so this is racy by nature but losing one hit
-		 * in a stat is not a big deal.
-		 */
-		__debug_atomic_inc(redundant_hardirqs_on);
-		return;
-	}
 	/* we'll do an OFF -> ON transition: */
 	curr->hardirqs_enabled = 1;
 
-	if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
-		return;
 	/*
 	 * We are going to turn hardirqs on, so set the
 	 * usage bit for all held locks:

@@ -2529,9 +2515,25 @@ void trace_hardirqs_on_caller(unsigned l
 	if (unlikely(!debug_locks || current->lockdep_recursion))
 		return;
 
+	if (unlikely(current->hardirqs_enabled)) {
+		/*
+		 * Neither irq nor preemption are disabled here
+		 * so this is racy by nature but losing one hit
+		 * in a stat is not a big deal.
+		 */
+		__debug_atomic_inc(redundant_hardirqs_on);
+		return;
+	}
+
 	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
 		return;
 
+	if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
+		return;
+
+	if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
+		return;
+
 	current->lockdep_recursion = 1;
 	__trace_hardirqs_on_caller(ip);
 	current->lockdep_recursion = 0;

Quoted 7 lines · Arnaud Lacombe

Quoted 4 lines

Peter Zijlstra (3):
     [...]
     lockdep: Fix trace_[soft,hard]irqs_[on,off]() recursion

This commit is triggering:

WARNING: at /src/linux/linux/kernel/lockdep.c:2529

Not actually having reproduced the problem, does the below cure things?

---
Subject: lockdep: Fix trace_hardirqs_on_caller()
From: Peter Zijlstra <[email protected]>
Date: Tue Jul 26 13:13:44 CEST 2011

Commit dd4e5d3ac4a ("lockdep: Fix trace_[soft,hard]irqs_[on,off]() recursion") made a bit of a mess of the various checks and error conditions.

In particular it moved the check for !irqs_disabled() before the spurious enable test, resulting in some warnings.

Reported-by Arnaud Lacombe <[email protected]>

Reported-by Dave Jones <[email protected]>

Reported-by Sergey Senozhatsky <[email protected]>

Signed-off-by Peter Zijlstra <[email protected]>

---
 kernel/lockdep.c |   30 ++++++++++++++++--------------

 1 file changed, 16 insertions(+), 14 deletions(-)

Index: linux-2.6/kernel/lockdep.c
===================================================================

kernel/lockdep.c +16 -14

@@ -2485,23 +2485,9 @@ static void __trace_hardirqs_on_caller(u
  {
        struct task_struct *curr = current;
 
-       if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
-               return;
-
-       if (unlikely(curr->hardirqs_enabled)) {
-               /*
-                * Neither irq nor preemption are disabled here
-                * so this is racy by nature but losing one hit
-                * in a stat is not a big deal.
-                */
-               __debug_atomic_inc(redundant_hardirqs_on);
-               return;
-       }
        /* we'll do an OFF -> ON transition: */
        curr->hardirqs_enabled = 1;
 
-       if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
-               return;
        /*
         * We are going to turn hardirqs on, so set the
         * usage bit for all held locks:

@@ -2529,9 +2515,25 @@ void trace_hardirqs_on_caller(unsigned l
        if (unlikely(!debug_locks || current->lockdep_recursion))
                return;
 
+       if (unlikely(current->hardirqs_enabled)) {
+               /*
+                * Neither irq nor preemption are disabled here
+                * so this is racy by nature but losing one hit
+                * in a stat is not a big deal.
+                */
+               __debug_atomic_inc(redundant_hardirqs_on);
+               return;
+       }
+
        if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
                return;
 
+       if (DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled)))
+               return;
+
+       if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
+               return;
+
        current->lockdep_recursion = 1;
        __trace_hardirqs_on_caller(ip);
        current->lockdep_recursion = 0;

[0]: I still have to find an easy way to transfer patch between gmail and my tree... For now, I ruled out mutt as it mangle the patch...

Quoted 3 lines · Arnaud Lacombe

[0]: I still have to find an easy way to transfer patch between gmail and my tree... For now, I ruled out mutt as it mangle the patch...

The gmail web interface on the *receiving* end is easy enough, and I do it all the time: just go to the per-email menu in the upper right corner of the email, and choose "Show original". Then you just save that, and you're done.

Sadly, the gmail web interface cannot *send* patches without whitespace-mangling them. You have to send them as attachements, and there is no way to say "do this attachement inline".

Sad, sad, sad. gmail gets so many other things right, but sending patches is a big pain in the *ss for no good reason.

The gmail web client also does threading the wrong way (by subject line rather than by following references), but that's apparently what Windows people want and are used to because of how Exchange works. Or so I've been told - I've never touched that pile of crap. It's sad how it has then resulted in crud in gmail. It's not like proper threading is some kind of unheard-of feature..

Sadly, the gmail web interface cannot *send* patches without whitespace-mangling them. You have to send them as attachements, and there is no way to say "do this attachement inline".