linux-toradex.git/drivers/scsi/scsi_sysfs.c, branch v3.14.33

scsi: fix our current target reap infrastructure

2014-05-31T20:20:27+00:00

commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream.

This patch eliminates the reap_ref and replaces it with a proper kref.
On last put of this kref, the target is removed from visibility in
sysfs.  The final call to scsi_target_reap() for the device is done from
__scsi_remove_device() and only if the device was made visible.  This
ensures that the target disappears as soon as the last device is gone
rather than waiting until final release of the device (which is often
too long).

Reviewed-by: Alan Stern 
Tested-by: Sarah Sharp 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

[SCSI] Set the minimum valid value of 'eh_deadline' as 0

2013-12-19T15:39:02+00:00

The former minimum valid value of 'eh_deadline' is 1s, which means
the earliest occasion to shorten EH is 1 second later since a
command is failed or timed out. But if we want to skip EH steps
ASAP, we have to wait until the first EH step is finished. If the
duration of the first EH step is long, this waiting time is
excruciating. So, it is necessary to accept 0 as the minimum valid
value for 'eh_deadline'.

According to my test, with Hannes' patchset 'New EH command timeout
handler' as well, the minimum IO time is improved from 73s
(eh_deadline = 1) to 43s(eh_deadline = 0) when commands are timed
out by disabling RSCN and target port.

Signed-off-by: Ren Mingxin 
Signed-off-by: Hannes Reinecke 
Signed-off-by: James Bottomley

[SCSI] Add 'eh_deadline' to limit SCSI EH runtime

2013-10-25T11:17:59+00:00

This patchs adds an 'eh_deadline' sysfs attribute to the scsi
host which limits the overall runtime of the SCSI EH.
The 'eh_deadline' value is stored in the now obsolete field
'resetting'.
When a command is failed the start time of the EH is stored
in 'last_reset'. If the overall runtime of the SCSI EH is longer
than last_reset + eh_deadline, the EH is short-circuited and
falls through to issue a host reset only.

[jejb: add comments in Scsi_Host about new fields]
Signed-off-by: Hannes Reinecke 
Signed-off-by: James Bottomley

[SCSI] export device_busy for sdev

2013-10-25T08:57:56+00:00

If you mutiple devices connect to a host, we might be interested in
have an intensive I/O workload on one disk, and notice starvation on others.
This give the user more hint about current infight io for scsi device.

Signed-off-by: Jack Wang 
Signed-off-by: James Bottomley

[SCSI] Generate uevents on certain unit attention codes

2013-08-26T14:52:27+00:00

Generate a uevent when the following Unit Attention ASC/ASCQ
codes are received:

    2A/01  MODE PARAMETERS CHANGED
    2A/09  CAPACITY DATA HAS CHANGED
    38/07  THIN PROVISIONING SOFT THRESHOLD REACHED
    3F/03  INQUIRY DATA HAS CHANGED
    3F/0E  REPORTED LUNS DATA HAS CHANGED

Log kernel messages when the following Unit Attention ASC/ASCQ
codes are received that are not as specific as those above:

    2A/xx  PARAMETERS CHANGED
    3F/xx  TARGET OPERATING CONDITIONS HAVE CHANGED

Added logic to set expecting_lun_change for other LUNs on the target
after REPORTED LUNS DATA HAS CHANGED is received, so that duplicate
uevents are not generated, and clear expecting_lun_change when a
REPORT LUNS command completes, in accordance with the SPC-3
specification regarding reporting of the 3F 0E ASC/ASCQ UA.

[jejb: remove SPC3 test in scsi_report_lun_change and some docbook fixes and
       unused variable fix, both reported by Fengguang Wu]
Signed-off-by: Ewan D. Milne 
Signed-off-by: James Bottomley

[SCSI] Allow error handling timeout to be specified

2013-06-04T18:16:24+00:00

Introduce eh_timeout which can be used for error handling purposes. This
was previously hardcoded to 10 seconds in the SCSI error handling
code. However, for some fast-fail scenarios it is necessary to be able
to tune this as it can take several iterations (bus device, target, bus,
controller) before we give up.

Signed-off-by: Martin K. Petersen 
Signed-off-by: James Bottomley

[SCSI] prevent stack buffer overflow in host_reset

2012-11-30T09:08:16+00:00

store_host_reset() has tried to re-invent the wheel to compare sysfs strings.
Unfortunately it did so poorly and never bothered to check the input from
userspace before overwriting stack with it, so something simple as:

echo "WoopsieWoopsie" >
/sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset

would result in:

[  316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7
[  316.310101]
[  316.320051] Pid: 6655, comm: sh Tainted: G        W    3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129
[  316.320051] Call Trace:
[  316.340058] pps pps0: PPS event at 1352918752.620355751
[  316.340062] pps pps0: capture assert seq #303
[  316.320051]  [] panic+0xcd/0x1f4
[  316.320051]  [] ? store_host_reset+0xd7/0x100
[  316.320051]  [] __stack_chk_fail+0x16/0x20
[  316.320051]  [] store_host_reset+0xd7/0x100
[  316.320051]  [] dev_attr_store+0x13/0x30
[  316.320051]  [] sysfs_write_file+0x101/0x170
[  316.320051]  [] vfs_write+0xb8/0x180
[  316.320051]  [] sys_write+0x50/0xa0
[  316.320051]  [] tracesys+0xe1/0xe6

Fix this by uninventing whatever was going on there and just use sysfs_streq.

Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and
firmware reset").

[jejb: added necessary const to prevent compile warnings]
Signed-off-by: Sasha Levin 
Cc:  #3.2+
Signed-off-by: James Bottomley

[SCSI] scsi_remove_target: fix softlockup regression on hot remove

2012-09-24T08:17:49+00:00

John reports:
 BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
 [..]
 Call Trace:
  [] scsi_remove_target+0xda/0x1f0
  [] sas_rphy_remove+0x55/0x60
  [] sas_rphy_delete+0x11/0x20
  [] sas_port_delete+0x25/0x160
  [] mptsas_del_end_device+0x183/0x270

...introduced by commit 3b661a9 "[SCSI] fix hot unplug vs async scan race".

Don't restart lookup of more stargets in the multi-target case, just
arrange to traverse the list once, on the assumption that new targets
are always added at the end.  There is no guarantee that the target will
change state in scsi_target_reap() so we can end up spinning if we
restart.

Cc: 
Acked-by: Jack Wang 
LKML-Reference: 
Reported-by: John Drescher 
Tested-by: John Drescher 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley

[SCSI] fix hot unplug vs async scan race

2012-07-20T07:58:45+00:00

The following crash results from cases where the end_device has been
removed before scsi_sysfs_add_sdev has had a chance to run.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
 IP: [] sysfs_create_dir+0x32/0xb6
 ...
 Call Trace:
  [] kobject_add_internal+0x120/0x1e3
  [] ? trace_hardirqs_on+0xd/0xf
  [] kobject_add_varg+0x41/0x50
  [] kobject_add+0x64/0x66
  [] device_add+0x12d/0x63a
  [] ? _raw_spin_unlock_irqrestore+0x47/0x56
  [] ? module_refcount+0x89/0xa0
  [] scsi_sysfs_add_sdev+0x4e/0x28a
  [] do_scan_async+0x9c/0x145

...teach scsi_sysfs_add_devices() to check for deleted devices() before
trying to add them, and teach scsi_remove_target() how to remove targets
that have not been added via device_add().

Cc: 
Reported-by: Dariusz Majchrzak 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley

[SCSI] Stop accepting SCSI requests before removing a device

2012-07-20T07:58:41+00:00

Avoid that the code for requeueing SCSI requests triggers a
crash by making sure that that code isn't scheduled anymore
after a device has been removed.

Also, source code inspection of __scsi_remove_device() revealed
a race condition in this function: no new SCSI requests must be
accepted for a SCSI device after device removal started.

Signed-off-by: Bart Van Assche 
Reviewed-by: Mike Christie 
Acked-by: Tejun Heo 
Signed-off-by: James Bottomley