summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2010-02-23 15:03:02 +0100
committerThomas Gleixner <tglx@linutronix.de>2010-02-23 17:16:29 +0100
commitdb811b97dd11cd1aa6d751e7d02fa73dc7b2ad4b (patch)
tree36bbf8d2324a8eae9c72490ee4701468b7fbdcc5
parenta40c206147b9c79d65c59edc5b9df874c88f1fb5 (diff)
downloadlwn-db811b97dd11cd1aa6d751e7d02fa73dc7b2ad4b.tar.gz
lwn-db811b97dd11cd1aa6d751e7d02fa73dc7b2ad4b.zip
core: Revert the in_irq() in_softirq() modifications
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>
-rw-r--r--include/linux/hardirq.h4
1 files changed, 2 insertions, 2 deletions
diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
index 8a2b0889a008..b5dec5053ebb 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->extra_flags & PFE_HARDIRQ))
-#define in_softirq() (softirq_count() || (current->extra_flags & PFE_SOFTIRQ))
+#define in_irq() (hardirq_count())
+#define in_softirq() (softirq_count())
#define in_interrupt() (irq_count())
/*