blob: 11ac1e8542e8934d15bd823c8966883cd2f381e4 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
From 7d9e9a8da2f01552ef468a9042fd2deed7800182 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>
---
include/linux/hardirq.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
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.0.4
|
