lkml.org 
[lkml]   [1999]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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