Messages in this thread | | | Date | Fri, 13 Nov 1998 19:14:40 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |