Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1353035
| From | Hannes Reinecke <hare@suse.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler |
| Date | 2016-03-08 14:30 +0100 |
| Message-ID | <rapS2-1q3-3@gated-at.bofh.it> (permalink) |
| References | <rap5E-Qj-7@gated-at.bofh.it> <rapfk-TU-15@gated-at.bofh.it> <rapyG-1hW-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 03/08/2016 02:01 PM, Hannes Reinecke wrote: > On 03/08/2016 01:35 PM, Yaniv Gardi wrote: >> A race condition exists between request requeueing and scsi layer >> error handling: >> When UFS driver queuecommand returns a busy status for a request, >> it will be requeued and its tag will be freed and set to -1. >> At the same time it is possible that the request will timeout and >> scsi layer will start error handling for it. The scsi layer reuses >> the request and its tag to send error related commands to the device, >> however its tag is no longer valid. >> As this request was never really sent to the device, there is no >> point to start error handling with the device. >> Implement the scsi error handling timeout callback and bypass SCSI >> error handling for request that were not actually sent to the device. >> For such requests simply reset the block layer timer. Otherwise, let >> SCSI layer perform the usual error handling. >> >> Reviewed-by: Dolev Raviv <draviv@codeaurora.org> >> Signed-off-by: Gilad Broner <gbroner@codeaurora.org> >> Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org> >> >> --- >> drivers/scsi/ufs/ufshcd.c | 36 ++++++++++++++++++++++++++++++++++++ >> 1 file changed, 36 insertions(+) >> > Having a timeout handler is always a good idea, even though this > doesn't do anything here. > Are we sure that the requests will return eventually? > Does the UFS spec provide for a command abort? > In fact, looking at the UFS spec there _is_ a command abort. I would recommend implementing a task management request UPIO with type 'ABORT TASK' here for any task found to be pending. In the end, you might run into a _valid_ timeout, at which point you really want to abort the command... Cheers, Hannes- -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v7 00/17] add fixes, device quirks, error recovery, Yaniv Gardi <ygardi@codeaurora.org> - 2016-03-08 13:40 +0100
[PATCH v7 05/17] scsi: ufs: add support to read device and string descriptors Yaniv Gardi <ygardi@codeaurora.org> - 2016-03-08 13:50 +0100
[PATCH v7 01/17] scsi: ufs-qcom: add number of lanes per direction Yaniv Gardi <ygardi@codeaurora.org> - 2016-03-08 13:50 +0100
[PATCH v7 08/17] scsi: ufs: make error handling bit faster Yaniv Gardi <ygardi@codeaurora.org> - 2016-03-08 13:50 +0100
[PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler Yaniv Gardi <ygardi@codeaurora.org> - 2016-03-08 13:50 +0100
Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler Hannes Reinecke <hare@suse.de> - 2016-03-08 14:10 +0100
Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler Hannes Reinecke <hare@suse.de> - 2016-03-08 14:30 +0100
Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler ygardi@codeaurora.org - 2016-03-08 21:00 +0100
Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler Hannes Reinecke <hare@suse.de> - 2016-03-09 07:50 +0100
Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler ygardi@codeaurora.org - 2016-03-08 14:40 +0100
[PATCH v7 07/17] scsi: ufs: disable vccq if it's not needed by UFS device Yaniv Gardi <ygardi@codeaurora.org> - 2016-03-08 13:50 +0100
csiph-web