Date: Wed, 20 Oct 2004 10:33:58 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Paul Mackerras <paulus@samba.org>
Cc: akpm@osdl.org, torvalds@osdl.org, anton@samba.org,
       benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
       Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] Fix PREEMPT_ACTIVE definition
Message-ID: <20041020083358.GB23396@elte.hu>
References: <16758.3807.954319.110353@cargo.ozlabs.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16758.3807.954319.110353@cargo.ozlabs.ibm.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1235
Lines: 30


* Paul Mackerras <paulus@samba.org> 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@samba.org>

Acked-by: Ingo Molnar <mingo@elte.hu>

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