Noriyuki Soda <soda@sra.co.jp> writes:

> 
> 1. change scsi_scsi_cmd(,... SCSI_NOSLEEP) behavior into returning
>   EWOULDBLOCK (or something like that), when (*sc_link->adapter->scsi_cmd)()
>   returns TRY_AGAIN_LATOR. 
>   (if SCSI_NOSLEEP is not specified,
>    or if (*sc_link->adapter->scsi_cmd)() doesn't return TRY_AGAIN_LATOR,
>    then scsi_scsi_cmd() behaves as it is.)
> 
> 2. sdstart(), ststart() and cdstart() check return value of
>   scsi_scsi_cmd(), and these remove `struct buf' from sc->buf_queue,
>   only if scsi_scsi_cmd() does not return EWOULDBLOCK.
>   That is, if scsi_scsi_cmd() returns EWOULDBLOCK, we leave
>   sc->buf_queue as it is, and immediately returns from xxstart().
>   (xxstart() continues to use SCSI_NOSLEEP.)
> 
> This fix seems to be easy to implement, and doesn't change traditional
> behavior of xxstart(). (xxstart() can be called from interrupt)

By itself, this isn't sufficient, because you wouldn't be guaranteed
to notify the higher-level driver when a slot (SCB) becomes available.
(Consider the case where other devices are currently hogging all the
slots.  There won't be a call to scsi_done() for that device, so its
start routine won't be called again unless someone queues another I/O
operation.)

Additionally, the behaviour suggested in item 2 would require either
disallowing the start routine from ever sleeping (meaning that it
would always have to use SCSI_NOSLEEP), or adding an additional lock
to prevent another process entering the start routine (from the
strategy routine) and trying to start the same buffer.

Also, if you disallow sleeping in the strategy routine (which would be
the only real point to completely disallowing it in the start
routine), this still doesn't solve the problem of where you allocate
resources.