kernel.git/drivers/scsi/scsi_sysfs.c, branch linux-3.2.y

scsi: avoid a permanent stop of the scsi device's request queue

2017-03-16T02:18:32Z

commit d2a145252c52792bc59e4767b486b26c430af4bb upstream. A race between scanning and fc_remote_port_delete() may result in a permanent stop if the device gets blocked before scsi_sysfs_add_sdev() and unblocked after. The reason is that blocking a device sets both the SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However, scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the device to be ignored by scsi_target_unblock() and thus never have its QUEUE_FLAG_STOPPED cleared leading to a device which is apparently running but has a stopped queue. We actually have two places where SDEV_RUNNING is set: once in scsi_add_lun() which respects the blocked flag and once in scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely spurious, simply remove it to fix the problem. Reported-by: Zengxi Chen Signed-off-by: Wei Fang Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings

scsi_sysfs: Fix queue_ramp_up_period return code

2015-11-27T12:48:24Z

commit 863e02d0e173bb9d8cea6861be22820b25c076cc upstream. Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period returns the value of that number instead of the number of bytes written. This behavior can confuse programs expecting POSIX write() semantics. Fix this by returning the number of bytes written instead. Signed-off-by: Peter Oberparleiter Reviewed-by: Hannes Reinecke Reviewed-by: Matthew R. Ochs Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings

scsi: restart list search after unlock in scsi_remove_target

2015-11-27T12:48:23Z

commit 40998193560dab6c3ce8d25f4fa58a23e252ef38 upstream. When dropping a lock while iterating a list we must restart the search as other threads could have manipulated the list under us. Without this we can get stuck in an endless loop. This bug was introduced by commit bc3f02a795d3b4faa99d37390174be2a75d091bd Author: Dan Williams Date: Tue Aug 28 22:12:10 2012 -0700 [SCSI] scsi_remove_target: fix softlockup regression on hot remove Which was itself trying to fix a reported soft lockup issue http://thread.gmane.org/gmane.linux.kernel/1348679 However, we believe even with this revert of the original patch, the soft lockup problem has been fixed by commit f2495e228fce9f9cec84367547813cbb0d6db15a Author: James Bottomley Date: Tue Jan 21 07:01:41 2014 -0800 [SCSI] dual scan thread bug fix Thanks go to Dan Williams for tracking all this prior history down. Reported-by: Johannes Thumshirn Signed-off-by: Christoph Hellwig Tested-by: Johannes Thumshirn Reviewed-by: Johannes Thumshirn Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

fix our current target reap infrastructure

2014-07-11T12:33:56Z

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: Ben Hutchings

Stop accepting SCSI requests before removing a device

2014-07-11T12:33:55Z

commit b485462aca7df4e32bcf7efb6f84a69e8b640243 upstream. 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 [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

prevent stack buffer overflow in host_reset

2013-01-03T03:33:21Z

commit 072f19b4bea31cdd482d79f805413f2f9ac9e233 upstream. 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 Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

scsi_remove_target: fix softlockup regression on hot remove

2012-10-17T02:48:50Z

commit bc3f02a795d3b4faa99d37390174be2a75d091bd upstream. 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. Acked-by: Jack Wang LKML-Reference: Reported-by: John Drescher Tested-by: John Drescher Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

fix hot unplug vs async scan race

2012-08-02T13:37:55Z

commit 3b661a92e869ebe2358de8f4b3230ad84f7fce51 upstream. 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(). Reported-by: Dariusz Majchrzak Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

Fix device removal NULL pointer dereference

2012-08-02T13:37:54Z

commit 67bd94130015c507011af37858989b199c52e1de upstream. Use blk_queue_dead() to test whether the queue is dead instead of !sdev. Since scsi_prep_fn() may be invoked concurrently with __scsi_remove_device(), keep the queuedata (sdev) pointer in __scsi_remove_device(). This patch fixes a kernel oops that can be triggered by USB device removal. See also http://www.spinics.net/lists/linux-scsi/msg56254.html. Other changes included in this patch: - Swap the blk_cleanup_queue() and kfree() calls in scsi_host_dev_release() to make that code easier to grasp. - Remove the queue dead check from scsi_run_queue() since the queue state can change anyway at any point in that function where the queue lock is not held. - Remove the queue dead check from the start of scsi_request_fn() since it is redundant with the scsi_device_online() check. Reported-by: Jun'ichi Nomura Signed-off-by: Bart Van Assche Reviewed-by: Mike Christie Reviewed-by: Tejun Heo Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings

[SCSI] scsi: Added support for adapter and firmware reset

2011-08-27T14:36:46Z

Added new sysfs attr 'host_reset' in scsi_sysfs.c to perform adapter or firmware reset as suggested by Mike Christie here: http://marc.info/?l=linux-scsi&m=127359347111167&w=2 user/application can write "adapter" or "firmware" on this attr and it will call newly added function hook in scsi_host_template to call LDD adapter or firmware reset implementation. Signed-off-by: Vikas Chaudhary Reviewed-by: Mike Christie Signed-off-by: James Bottomley