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