On Fri, Jun 11, 2004 at 02:09:11PM +0000, Kevin Corry wrote: > > After talking to Alasdair a bit, it seems like there still might be a reason > for using the interruptible wait in sync_io(). The point he brought up was > that if you are using dm-io to do I/O to another DM device, and that DM device > is suspended, then the I/O may never complete if the device doesn't get > unsuspended (for some reason). In this case, you'd like to be able to > interrupt the process that's waiting for that I/O so it isn't stuck in D-state > forever. After thinking about this a little more, I vote a strong NO against making this interface interruptible. The interface can't be made "signal safe". Allowing signals to interrupt would be an invitation for memory corruption problems. Imagine an application using this interface. It allocates some pages and submits a synchronous read of some disk sectors into those pages. Now the interface returns EINTR. At this time, those IO's are still pending. They will complete some day. What does this application do with those pages in the mean time. They can't be freed. I think a better solution would be to NOT allow signal delivery. Instead, arrange a mechanism to FAIL those pending IO's and all IO's that are newly submitted. Imagine again the case where a mapping is suspended. All IO's that were in progress before the suspend will complete. IO's that are submitted after the suspend will be queued and remain pending. Now, add an iocl DM_FAILIO to the device mapper that terminates those pending IO's with errors and fails any newly submitted IO. Maybe add another IOCTL, DM_ALLOW_IO, to allow new IO to be queued until the target is resumed. Or maybe a better mechanism would be to replace the targets in the mapping with the error target and resume.. How does this sound? Dave