Messages in this thread | | | Date | Mon, 10 Jan 2005 12:02:52 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 2.6.10-mm2] Use the new preemption code [2/3] Resend |
| |
* Thomas Gleixner <tglx@linutronix.de> wrote:
> > Are you sure ARM suffers from this race condition? It sets preempt count > > before enabling IRQs and doesn't use preempt_schedule(). > > There is no race for arm, but using the preempt_schedule() interface > is the approach which Ingo suggested for common usage, but his x86 > implementation was racy, so I fixed this first before modifying arm to > use the interface. Ingo pointed out that he will change it to > preempt_schedule_irq, but I'm not religious about the name.
i wouldnt raise this issue if it was the name only, but there's more to preempt_schedule_irq() than its name: it gets called with irqs off and the scheduler returns with irqs off and with a guarantee that there is no (irq-generated) pending preemption request for this task right now. I.e. the checks for need_resched can be skipped, and interrupts dont have to be disabled to do a safe return-to-usermode (as done on some architectures).
as far as i can see do_preempt_schedule() doesnt have these properties: what it guarantees is that it avoids the preemption recursion via the lowlevel code doing the PREEMPT_ACTIVE setting.
lets agree upon a single, common approach. I went for splitting up preempt_schedule() into two variants: the 'synchronous' one (called preempt_schedule()) is only called from syscall level and has no repeat-preemption and hence stack-recursion worries. The 'asynchronous' one (called preempt_schedule_irq()) is called from asynchronous contexts (hardirq events) and is fully ready to deal with all the reentrancy situations that may occur. It's careful about not re-enabling interrupts, etc.
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/
| |