Re: scheduler: IRQs disabled over context switches

[Davide Libenzi]

On Mon, 24 May 2004, Russell King wrote:

> On Sun, May 23, 2004 at 04:04:39PM -0700, Davide Libenzi wrote:
> > On Sun, 23 May 2004, Russell King wrote:
> > > Not quite - look harder.  They use spin_unlock_irq in finish_arch_switch
> > > rather than prepare_arch_switch.
> > 
> > Hmm, they do indeed. Hmm, if we release the rq lock before the ctx switch, 
> > "prev" (the real one) will result not running since we already set 
> > "rq->curr" to "next" (and we do not hold "prev->switch_lock").
> 
> We do hold prev->switch_lock - we hold it all the time that the thread
> is running.  Consider what prepare_arch_switch() is doing - it's taking
> the next threads switch_lock.  It only gets released _after_ we've
> switched away from that thread.

It is flawed indeed :) (/me looking at it after ages). Even looking at the 
scheduler tick code, it does not play with mm fields, so it should be fine 
after the rq lock (and IRQ) release. Preempt is fine due to the preempt_disable()
(plus switch_lock held), tasks result running (due switch_lock held) so 
remote CPUs won't touch them, and scheduler_tick() looking innocuous with 
respect to the fields that matters for switch. Is it blowing up on ARM?



- Davide

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