linux-kernel - [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-next>] [day] [month] [year] [list]

Message-ID: <52441C1F.8020200@nvidia.com>
Date:	Thu, 26 Sep 2013 17:05:59 +0530
From:	Vishal Annapurve <vannapurve@...dia.com>
To:	<linux-kernel@...r.kernel.org>
Subject: [PATCH] usb-storage: scsiglue: Changing the command result

Hi,

There was a recent commit in mainline for the scsi devices which do not
respond properly to medium access command:

commit    18a4d0a22ed6c54b67af7718c305cd010f09ddf8

[SCSI] Handle disk devices which can not process medium access commands
We have experienced several devices which fail in a fashion we do not
currently handle gracefully in SCSI. After a failure these devices will
respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.)
but any command accessing the storage medium will time out.

I came across a USB drive which showed similar problem and what I see is
usb storage is still not able to cope with such devices properly.

The control flow downwards is like:
scsi_times_out --> Setting cmd->result as DID_TIME_OUT
scsi_error_handler
scsi_unjam_host
scsi_eh_abort_cmds
command_abort    (sets US_FLIDX_TIMED_OUT for us->dflags
                                   calls stop_transport,
                                   and waits for)    usb_stor_control_thread (which is waiting for
                                                                    transport call to return inside
                                                                    usb_stor_invoke_transport)
                                                                    both usb_stor_control_thread and
                                                                    usb_stor_invoke_transport
                                                     check for us->dflags timed_out bit and
                                                      set the result as DID_ABORT
                                                      and signal completion for command_abort
                                                      to complete
......
sd_eh_action
checks for cmd->result and finds out that it's DID_ABORT rather than
DID_TIME_OUT.

This patch updates the command result to be TIME_OUT explicitly before
returning from command_abort in scsiglue.c.

I would like to know if this patch can work out for such USB Storage
devices? What would be the better way to do the same?

Regards,
Vishal Annapurve

View attachment "usb_storage_scsi_medium_access_timeout.patch" of type "text/x-patch" (1148 bytes)