Messages in this thread | | | Subject | Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler | From | Hannes Reinecke <> | Date | Tue, 8 Mar 2016 14:01:23 +0100 |
| |
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?
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)
| |