On Wed, 2016-10-26 at 08:42 -0700, Bart Van Assche wrote: > On 10/25/2016 04:50 PM, James Bottomley wrote: > > On Tue, 2016-10-25 at 23:18 +0000, Bart Van Assche wrote: > > > Anyway, currently the following functions interpret the SCSI > > > sense buffer: > > > * scsi_io_completion() in scsi_lib.c. > > > * scsi_mode_sense() in scsi_lib.c. > > > * scsi_test_unit_ready_flags() in scsi_lib.c. > > > * scsi_probe_lun() in scsi_scan.c. > > > * scsi_report_lun_scan() in scsi_scan.c. > > > * ioctl_internal_command() in scsi_ioctl.c. > > > * sg_rq_end_io() in sg.c. > > > * scsi_check_sense() in scsi_error.c. > > > * spi_execute() in scsi_transport_spi.c. > > > > > > Are you sure we should add sense code interpretation code in a > > > tenth function in the SCSI core? > > > > In the absence of a better proposal, yes. I originally looked into > > better BLOCK_PC error handling in scsi_io_completion, but that has > > some knock on problems, so it seems best to leave it alone. > > Can you elaborate on this? Since the sense buffer is available in > scsi_io_completion() and since that function already calls > scsi_command_normalize_sense() this function seems like a good > candidate to me to add retry logic for REQ_TYPE_BLOCK_PC requests.
UAs are used to signal AENs to userspace control processes that use BLOCK_PC, like CD changers, burners and scanners. If we eat UAs inside scsi_io_completion(), we could potentially break any userspace control system that relies on AENs. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
