> protecting them with a combination of interrupt disables and
> spin_locks. Preemption is allowed (incorrectly) if
> interrupts are off and preempt_count goes to zero on the
> spin_unlock. I will wager that this is an SMP machine.
> After the preemption interrupts will be on (schedule() does
> that) AND you could be on a different cpu. Either of these
> is a BAD thing.
>
> The proposed fix is to catch the attempted preemption in
> preempt_schedule() and just return if the interrupt system
> is off. (Of course there is more that this to it, but I do
> believe that the problem is known. You could blow this
> assertion out of the water by asserting that the machine is
> NOT smp.)
I haven't looked at it further than gathering oopses and idly browsing
surrounding code. About your assertion, you're almost right, its UP box
running an SMP kernel w/ CONFIG_PREEMT.
-- function.linuxpower.ca- 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/