Re: manipulating sigmask from filesystems and drivers

[David Woodhouse]

[e-mail] 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