linux-kernel - Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56DECD23.7090704@suse.de>
Date:	Tue, 8 Mar 2016 14:01:23 +0100
From:	Hannes Reinecke <hare@...e.de>
To:	Yaniv Gardi <ygardi@...eaurora.org>,
	James.Bottomley@...senPartnership.com
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, santoshsy@...il.com,
	linux-scsi-owner@...r.kernel.org,
	Gilad Broner <gbroner@...eaurora.org>,
	Vinayak Holikatti <vinholikatti@...il.com>,
	"James E.J. Bottomley" <JBottomley@...n.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCH v7 03/17] scsi: ufs: implement scsi host timeout handler

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@...eaurora.org>
> Signed-off-by: Gilad Broner <gbroner@...eaurora.org>
> Signed-off-by: Yaniv Gardi <ygardi@...eaurora.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@...e.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)