lkml.org 
[lkml]   [1998]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: prev->has_cpu
On Fri, 13 Nov 1998, Linus Torvalds wrote:

>The patch has a serious bug: it marks the new CPU too late (after the
>switch). That, in turn, means that if any interrupts come in at a bad time
>that want to look at the CPU number, they get a stale value.

Right. Escuse me for the spam. I understood that after some seconds (but
was too late and I was on train when I understood that...).

>Why would you want to move the setting?

The ->processor setting is OK before the switch_to() and done on the
`next' process (this because we have the real CPU number only in the
kernel stack of the prev process and that number got automagically
invalidated after the switch_to()).

It' s the place where ->has_cpu is set, that it' s wrong according to me
(I still think that now?!?).

The point is that we _always_ set prev->use_cpu to 0. So if we are not
going to switch_to() we' ll continue with current->use_cpu set to 0 and
we' ll have a still sleeping process with use_cpu set to 1. There are some
kind of loop in exit.c that could harm in SMP, if, for mistake, a sleeping
process has use_cpu set to 1 I think:

/*
* Wait to make sure the process isn't active on any
* other CPU
*/
for (;;) {
int has_cpu;
spin_lock(&scheduler_lock);
has_cpu = p->has_cpu;
spin_unlock(&scheduler_lock);
if (!has_cpu)
break;
do {
barrier();
} while (p->has_cpu);
}
Please excuse me if I am missing something...

Andrea Arcangeli


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans