[lkml]   [1999]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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