On Thu, Jul 21, 2011 at 10:40:23PM +0200, Arnd Bergmann wrote:
On Thursday 21 July 2011 16:47:48 Mark Brown wrote:
Although the bigger problem is why are these interruptible? That's very unusual.
Well, the default should really be to use _interruptible or at least _killable with the appropriate error handling, and only use noninterruptible locks in cases where that's not possible.
In the funtions that Shawn pointed out, there is an error return, so it would be possible to do that, but the callers would need to be audited carefully.
We went round this analysis already with the underlying I2C drivers (which also end up needing to take mutexes and so on) - it really does work out better to just make the I/O noninterruptible, the I/O is fast enough to not really be worth interrupting and the handling for actual I/O errors should normally be sufficiently different to that for user initiated aborts that it just adds complication.
For example, if the user interrupts while we're in the middle of some lengthy series of operations or wait what we really want to do is to tear down the high level thing we're doing in an orderly fashion. If we allow the interrupt to be noticed as part of an I/O operation then what we often end up doing is failing that and we then have to work out why the I/O failed, if actually happened on a physical level and how we deal with that. Usually none of these paths will be well tested.
The overall result is that the system generally becomes more complicated and less robust.