Re: sg MiB writes scheduling while atomic

[Matthew Wilcox <willy@debian.org>]

On Tue, Sep 16, 2003 at 04:35:07PM +1000, Douglas Gilbert wrote:
> A user process is doing IO and the user decides to kill the
> process while a command is "in flight". After the user hits
> Ctrl+C, sg_close() is called and the sg driver lets it go
> through (i.e. doesn't hold the user process in an unkillable
> wait). Since the sg driver knows a command done notification
> is coming (callback to sg_cmd_done()) then it keeps all its
> related instances alive (including the scsi_device instance)
> and notes this situation by setting its sfp->close flag.
> 
> When the callback arrives, the respone is discarded and if
> this is the last outstanding command on this device then
> scsi_device_put(sdp->device) is called. scsi_device_put()
> isn't designed to be called from such a context. However sg
> (and all other upper level drivers I suspect) have no suitable
> context to call scsi_device_put() from in this situation.
> 
> Holding the sg_close() until the response arrives is an ugly
> solution. Any better suggestions?

scsi_device_put() calls down_write() so it needs to be called in process
context.  Probably the best way to do this is by calling schedule_work().
An ickier solution would be to hijack an error handling thread ;-)

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk