lkml.org 
[lkml]   [2004]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: scheduler: IRQs disabled over context switches
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.387 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site