On Friday 22 July 2011, Mark Brown wrote:
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.
Yes, that makes sense. There are also cases where a mutex should really be a spinlock (which is by definition not interruptible), or vice versa. I don't know if this is one of them.
I agree that the safest solution here is to just make the mutex uninterruptible.
Arnd