linux-kernel - RE: [PATCH] usb-storage: scsiglue: Changing the command result

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]

Date:	Sat, 19 Oct 2013 17:02:40 +0530
From:	Vishal Annapurve <vannapurve@...dia.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Ming Lei <tom.leiming@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>
Subject: RE: [PATCH] usb-storage: scsiglue: Changing the command result

Hi,

Attaching the new patch which will replace all the occurrences of DID_ABORT
with DID_TIMOUT in USB Storage whenever it sees US_FLIDX_TIMED_OUT bit
is set.

Regards,
Vishal

-----Original Message-----
From: Alan Stern [mailto:stern@...land.harvard.edu] 
Sent: Friday, October 18, 2013 4:10 PM
To: Vishal Annapurve
Cc: Ming Lei; Linux Kernel Mailing List; linux-usb
Subject: RE: [PATCH] usb-storage: scsiglue: Changing the command result

On Fri, 18 Oct 2013, Vishal Annapurve wrote:

> Hi Alan,
> 
> What I wanted to say was If the bit US_FLIDX_TIMED_OUT can have more 
> meanings than timed out then maybe it would be best to override the 
> results after usb-storage is done with the command maybe in scsi layer 
> itself who aborted it in the first place.

US_FLIDX_TIMED_OUT has one very specific meaning: command_abort() was called.

Since command_abort() is the .eh_abort_handler routine, US_FLIDX_TIMED_OUT means that the SCSI layer decided to abort the command.

Does the SCSI layer ever abort a command for any reason other than a timeout?  If not, you may conclude that US_FLIDX_TIMED_OUT indicates a timeout.  But if it does, you should not make this conclusion.

> My concern was that overriding the result in usb storage or scsi 
> layers will have more side effects than doing it in scsiglue.c.
> And by scsi-usb storage bridge what I meant was specifically the code 
> in scsiglue.
> 
> Question about your last mail, do you want to change all the 
> occurrences of DID_ABORT from usb-storage to DID_TIMEOUT?

Put it this way: There's no good reason for changing some of them but not all of them.

And if you're going to change them at all, it makes no sense to first set the result to DID_ABORT and then change it to DID_TIMEOUT.  You should simply set it to DID_TIMEOUT in the first place.

Alan Stern

Download attachment "usb_storage_change_abort_to_timeout.patch" of type "application/octet-stream" (2754 bytes)