Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752770AbcCHNUr (ORCPT ); Tue, 8 Mar 2016 08:20:47 -0500 Received: from mx2.suse.de ([195.135.220.15]:42433 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751000AbcCHNUh (ORCPT ); Tue, 8 Mar 2016 08:20:37 -0500 Subject: Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler To: Yaniv Gardi , James.Bottomley@HansenPartnership.com References: <1457440568-13084-1-git-send-email-ygardi@codeaurora.org> <1457440568-13084-4-git-send-email-ygardi@codeaurora.org> <56DECD23.7090704@suse.de> Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org, santoshsy@gmail.com, linux-scsi-owner@vger.kernel.org, Gilad Broner , Vinayak Holikatti , "James E.J. Bottomley" , "Martin K. Petersen" From: Hannes Reinecke Message-ID: <56DED1A2.2060609@suse.de> Date: Tue, 8 Mar 2016 14:20:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56DECD23.7090704@suse.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1985 Lines: 45 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 >> Signed-off-by: Gilad Broner >> Signed-off-by: Yaniv Gardi >> >> --- >> 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)