zaitcev@redhat.com said:
> Consider this. An application writes to /dev/dsp0, and ymfpci (for
> example) start DMA. Then user interrupts the app with ^C. When ymfpci
> gets ->release() call, it has to tell the chip to stop DMA, then wait
> until it's complete. If it tries to wait with TASK_INTERRUPTIBLE,
> schedule() will return immediately, and in essense do a busy loop with
> CPU pegged at 100%.
Forgive me; it's late here. What's wrong with -ERESTARTNOINTR?
But even if that's not going to work -- as I said later, there _are_ cases
where you can't really get rid of it. And given the debates we've had
recently about the return value from close(), your release() call seems like
one such, if you really can't restart it.
My point was that we should be making TASK_UNINTERRUPTIBLE _less_ attractive
to encourage people not to use it simply because it's easier than thinking
about the cleanup path, rather than making it more attractive as was
originally suggested.
> Same thing happens in USB, only there it's worse: a spinning
> application locks out khubd and whole subsistem dies.
Spinning is obviously wrong. If after thinking hard about it you can't come
up with a better solution, go pick up a form, find 5 kernel hackers to sign
it saying there really is no better solution, and you can have one of these
licences to use TASK_UNTERRUPTIBLE that I was talking about :)
-- dwmw2- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:17 EST