diff options
author | Thomas Gleixner <tglx@linutronix.de> | 2010-02-23 15:03:02 +0100 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2010-02-23 17:16:29 +0100 |
commit | db811b97dd11cd1aa6d751e7d02fa73dc7b2ad4b (patch) | |
tree | 36bbf8d2324a8eae9c72490ee4701468b7fbdcc5 | |
parent | a40c206147b9c79d65c59edc5b9df874c88f1fb5 (diff) | |
download | lwn-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.h | 4 |
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()) /* |