Messages in this thread | | | Date | Thu, 13 May 1999 16:19:48 -0700 (PDT) | From | Dimitris Michailidis <> | Subject | Re: Potential 2.2.8 scheduler bugs |
| |
On 13-May-99 Andrea Arcangeli wrote: > On Thu, 13 May 1999, Ingo Molnar wrote: > >>> On another front, release() in exit.c contains the following piece >>> of code: [...] > > I think that this race will never trigger but according to me rmb() > may be > still desiderable. We must make sure to read p->has_cpu after > p->state. > > Maybe our CPU reads p->has_cpu and see 0, before reading p->state and > seeing TASK_ZOMBIE, and between the two reads the other cpu scheduled > the > task `p' and the task `p' exits and p->state get set to ZOMBIE but > do_exit > has still to complete (has_cpu is 1 but the other CPU think it's 0 > because it read has_cpu out of order). >
Consider what happens when the exiting process is scheduled for the last time (when it is still runnable, not when it has changed its state to zombie). The wmb() in __schedule_tail() should make all CPUs see that has_cpu=1 for this process. This is before the process becomes a zombie, so when a process sees that p->state= TASK_ZOMBIE it cannot have a stale p->has_cpu=0. I don't see the need for a barrier in this piece of code. It appears to me that
while (p->has_cpu) ;
should be enough.
------ Dimitris Michailidis dimitris@engr.sgi.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |