Messages in this thread | | | Date | Mon, 1 Mar 1999 19:14:54 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [patch] entry.S calling schedule() with interrupts disabled, 2.2.2 |
| |
On Mon, 1 Mar 1999, Linus Torvalds wrote:
> Why not? There are tons of good reasons to disable interrupts on > scheduling, often because you want to avoid races with the people waking > you up, or something like that. > > cli(); > while (not_ready) { > waiting = 1; > current->state = TASK_UNINTERRUPTIBLE; > schedule(); > } > .. ok, we have some data now ..
maybe i'm misunderstanding something, but i'm trying to catch exactly such code, because i think it's buggy. schedule() does not guarantee that the 'interrupt state' (IF on UP, the more complex interrupt state on SMP) is preserved. In schedule() we do a release_kernel_lock(), which does an implicit __sti(). Then we do a reaquire_kernel_lock(), which gets the lock and leaves interrupts enabled. So if the above code relied on being in cli() mode in the loop (and it apparently does), we'd get a subtle bug. We explicitly catch the 'late wakeup' case anyway. (although this might be more an artifact of the complexity of the scheduler)
OTOH, so far the debugging code has not succeeded in finding any such 'true' place :)
even if schedule() does not matter, i find it slightly confusing and unrobust that we carry the 'local interrupts are disabled' state from interrupts into 'system call-level' code: the signal-check, reschedule-check and bh-check in ret_from_sys_call. The signals-related subtle lockup fixed recently was exactly due to that.
-- mingo
- 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/
| |