On Tue, 2016-10-25 at 23:18 +0000, Bart Van Assche wrote: > On Tue, 2016-10-25 at 15:23 -0700, James Bottomley wrote: > > Because scsi_execute uses REQ_BLOCK_PC which is completed before > > you get to that code. > > Hello James, > > Do you perhaps mean that scsi_io_completion() returns early for > REQ_TYPE_BLOCK_PC requests? Can you clarify this further? I'm not sure how much simpler I can make it. How about: the first if block gives a non zero value in error causing scsi_end_request to signal an immediate return? > 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. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
