Re: [PATCH] Fix PREEMPT_ACTIVE definition

[Ingo Molnar]

* Paul Mackerras <paulus@xxxxxxxxx> wrote:

> When the generic IRQ stuff went in, it seems that HARDIRQ_BITS got
> bumped from 9 (for ppc64) up to 12.  Consequently, the PREEMPT_ACTIVE
> bit is now within HARDIRQ_MASK, and I get in_interrupt() falsely
> returning true when PREEMPT_ACTIVE is set, and thus a BUG_ON tripping
> in arch/ppc64/mm/tlb.c.

indeed! The reason why this problem didnt trigger on the other
architectures is that the in_atomic() test is separate and excludes
PREEMPT_ACTIVE.

> The patch below fixes this by changing PREEMPT_ACTIVE to 0x10000000. I
> have changed the PREEMPT_ACTIVE definitions for each of the
> architectures that define CONFIG_GENERIC_HARDIRQS (i386, ppc, ppc64,
> x86_64) and fixed the comment in include/linux/hardirq.h.  We could
> perhaps move the PREEMPT_ACTIVE definition to include/linux/hardirq.h
> - I don't know why it is still per-arch.
> 
> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx>

Acked-by: Ingo Molnar <mingo@xxxxxxx>

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/