sg driver and the error handler

Alan Stern
2005-05-10T18:51:45Z

I don't know who the right person is to handle this, but maybe someone can
help...

When a command injected through the sg driver encounters any sort of
error, the usual retry mechanism and error handler are brought into play.
Since sg sets the number of retries to 0 by default, the retry mechanism
shouldn't cause any difficulty. But the error handler does. IMO it
should never get involved with requests coming through sg -- sg should
provide access that is as transparent as possible so that userspace
programs will have a clean shot at managing their device.

Consider a case that just came up. A USB CD drive causes a phase error
when it receives a certain READ BUFFER command (buggy firmware on the
drive, never mind that now). You would expect the user program to receive
from sg a host_status value indicating DID_ERROR or something of the sort.

Instead the error handler takes charge and sends out one or two TEST UNIT
READY commands. The status information finally received by the user
program is the status from the TEST UNIT READY, not from the failed READ
BUFFER! How's a program supposed to cope with that sort of obfuscation?

Something in the SCSI stack (scsi_io_completion ?) should check for
requests coming in via sg and should know to complete the requests
immediately. No requeuing and no error handling.

Does this sound like a feasible thing to implement?

Alan Stern