[dm-devel] [RFC, PATCH] remove signal handling from dm-io.c, sync_io()

[Dave Olien]

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