core-Revert-the-in_irq-in_softirq-modifications.patch

From 3daf998b12ce605e4a3fa81fce0633050182e3a3 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 23 Feb 2010 15:03:02 +0100
Subject: [PATCH] core: Revert the in_irq() in_softirq() modifications

commit db811b97dd11cd1aa6d751e7d02fa73dc7b2ad4b in tip.

RT added a check check for running in an interrupt handler thread or a
softirq thread to in_irq() and in_softirq().

Most of the users of these checks do not care, but RCU and perf_events
end up making wrong decisions. Especially the check in
rcu_read_unlock_special()

        /* Hardware IRQ handlers cannot block. */
        if (in_irq()) {
                local_irq_restore(flags);
                return;
        }

falls flat on his nose on -RT due to this.

Revert the changes and simply check for hardirq_count()
resp. softirq_count() as mainline does.

I checked all the users and the only dubious one is
dev_kfree_skb_any() but some hysteric research and talking to acme
makes me sure that it has no weird side effects.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
index 3223348..b5dec50 100644
--- a/include/linux/hardirq.h
+++ b/include/linux/hardirq.h
@@ -83,8 +83,8 @@
  * Are we doing bottom half or hardware interrupt processing?
  * Are we in a softirq context? Interrupt context?
  */
-#define in_irq()	(hardirq_count() || (current->flags & PF_HARDIRQ))
-#define in_softirq()	(softirq_count() || (current->flags & PF_SOFTIRQ))
+#define in_irq()	(hardirq_count())
+#define in_softirq()	(softirq_count())
 #define in_interrupt()	(irq_count())
 
 /*
-- 
1.7.1.1