Subject: Re: 2.6.12-rc2 in_atomic() picks up preempt_disable()
From: Arjan van de Ven <arjan@infradead.org>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: kaos@sgi.com, linux-kernel@vger.kernel.org, mingo@elte.hu
In-Reply-To: <200504071840.j37Iei25019895@harpo.it.uu.se>
References: <200504071840.j37Iei25019895@harpo.it.uu.se>
Content-Type: text/plain
Date: Thu, 07 Apr 2005 22:17:18 +0200
Message-Id: <1112905038.6290.77.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1334
Lines: 29

On Thu, 2005-04-07 at 20:40 +0200, Mikael Pettersson wrote:
> On Thu, 07 Apr 2005 12:17:37 +0200, Arjan van de Ven wrote:
> >On Thu, 2005-04-07 at 20:10 +1000, Keith Owens wrote:
> >> 2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG.  The
> >> in_atomic() macro thinks that preempt_disable() indicates an atomic
> >> region so calls to __might_sleep() result in a stack trace.
> >
> >but you're not allowed to schedule when preempt is disabled!
> 
> That sounds draconian. Where is that requirement stated?
> 
> A preempt-disabled region ought to have the same semantics
> as in a CONFIG_PREEMPT=n kernel, and since schedule is Ok
> in the latter case it should be Ok in the former too.
> 
> All that preempt_disable() should do is prevent involuntary
> schedules. But the conditional schedules introduced by may-sleep
> functions are _voluntary_, so there's no reason to forbid them.

but that implies you need to remember this after schedule. all in all it
starts to smell more and more like the local irq disable flag, and I at
least thing of it in a very similar way as well.


-
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/