Messages in this thread | | | Date | Sun, 28 Jan 2001 17:07:03 +0000 (GMT) | From | David Woodhouse <> |
| |
On Sun, 28 Jan 2001, Manfred Spraul wrote:
> It isn't wrong to call schedule() with disabled interrupts - it's a > feature ;-) > Those 10% sleep_on() users that aren't broken use it: > > for(;;) { > cli(); > if(condition) > break; > sleep_on(&my_wait_queue); > sti(); > }
That's valid iff the wake_up() can only happen from an ISR.
> E.g. TIOCMIWAIT in drivers/char/serial.c - a nearly correct sleep_on() > user.
TIOCMIWAIT does restore_flags() before interruptible_sleep_on(). It's broken too.
Anyway, if you're feeling pedantic, consider what happens if shutdown() is called from rs_close() just before sleep_on() is called. Regardless of whether interrupts are disabled.
> But I doubt that 10% of the sleep_on() users are non-broken...
There are cases where you don't care if you miss a wakeup because you have a timeout. So it's only suboptimal rather than broken. I did produce a patch to BUG() in sleep_on if the BKL isn't held, at one point. It was quite interesting.
> If you remove sleep_on(), then you can disallow calling schedule() with > disabled local interrupts.
The remaining valid users of sleep_on are mainly filesystems - much fs code gets called with the BKL held. I expect that to change during 2.5, at which point sleep_on can be terminated with extreme prejudice.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |