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:	Fri, 18 Oct 2013 10:10:12 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Vishal Annapurve <vannapurve@...dia.com>
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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/