Re: [RFC] 2.5 TASK_INTERRUPTIBLE preemption race

[Joe Korty <joe.korty@ccur.com>]

On Mon, Apr 14, 2003 at 06:00:42PM -0400, Robert Love wrote:
> On Mon, 2003-04-14 at 17:54, Joe Korty wrote:
> 
> > Is this analysis correct?  If it is, perhaps there is an alternative
> > to fixing these cases individually: make the TASK_INTERRUPTIBLE/
> > TASK_UNINTERRUPTIBLE states block preemption.  In which case the
> > 'set_current_state(TASK_RUNNING)' macro would need to include the
> > same preemption check as 'preemption_enable'.
> 
> Thankfully you are wrong or we would have some serious problems :)
> 
> See kernel/sched.c :: preempt_schedule() where we set p->preempt_count
> to PREEMPT_ACTIVE.
> 
> Then see kernel/sched.c :: schedule() where we short-circuit the
> remove-from-runqueue code if PREEMPT_ACTIVE is set.
> 
> Thus, it is safe to preempt regardless of the task's state.  It will
> eventually reschedule.
> 
> 	Robert Love


I see.  It is because the 'goto pick_next_task' skips the
'deactivate_task' call.  Therefore the previous task remains on the
run queue in spite of its TASK_UNINTERRUPTIBLE state.  Clever!

Joe