* Mikael Pettersson <[EMAIL PROTECTED]> 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?
(in the code, and in lkml discussions, as usual. There's tons of code
that correctly handled it and continues to handle it. Let me be clear,
this isnt some obscure side-effect, this is one of the cornerstones,
preempt_disable()/enable() always had these semantics, and this is very
much being relied on in a number of areas.)
> 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.
this just hides bugs and introduces bugs. From a critical section POV a
voluntary preemption is almost the same thing as a voluntary preemption
- the task may wander to another CPU, and smp_processor_id() might
become different. If it's not a problem for your code to preempt then
just enable preemption before calling it. Anyway, preempt_disable() /
preempt_enable() is pretty much an internal interface and shouldnt be
used lightly.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
