From 7d9e9a8da2f01552ef468a9042fd2deed7800182 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner 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 Signed-off-by: Paul Gortmaker --- 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