linux-stable.git/drivers/scsi, branch v4.12.7

scsi: sg: only check for dxfer_len greater than 256M

2017-08-13T02:34:28+00:00

commit f930c7043663188429cd9b254e9d761edfc101ce upstream.

Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the
sg_io_hdr_t::dxferp in order to determine if it is a valid request. The
only way we can check for bad requests is by checking if the length
exceeds 256M.

Signed-off-by: Johannes Thumshirn 
Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the
request)
Reported-by: Jason L Tibbitts III 
Tested-by: Jason L Tibbitts III 
Suggested-by: Doug Gilbert 
Cc: Doug Gilbert 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: lpfc: fix linking against modular NVMe support

2017-08-11T15:33:49+00:00

commit cd069bb9f9ff13b23492fda6ccdb458ac4f641ca upstream.

When LPFC is built-in but NVMe is a loadable module, we fail to link the
kernel:

drivers/scsi/built-in.o: In function `lpfc_nvme_create_localport':
(.text+0x156a82): undefined reference to `nvme_fc_register_localport'
drivers/scsi/built-in.o: In function `lpfc_nvme_destroy_localport':
(.text+0x156eaa): undefined reference to `nvme_fc_unregister_remoteport'

We can avoid this either by forcing lpfc to be a module, or by disabling
NVMe support in this case. This implements the former.

Fixes: 7d7080335f8d ("scsi: lpfc: Finalize Kconfig options for nvme")
Link: https://patchwork.kernel.org/patch/9636569/
Signed-off-by: Arnd Bergmann 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: virtio_scsi: always read VPD pages for multiqueue too

2017-07-27T22:10:08+00:00

commit a680f1d463aeaeb00d22af257a56e111967c2f18 upstream.

Multi-queue virtio-scsi uses a different scsi_host_template struct.  Add
the .device_alloc field there, too.

Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0
Cc: David Gibson 
Signed-off-by: Paolo Bonzini 
Reviewed-by: Fam Zheng 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: Avoid that scsi_exit_rq() triggers a use-after-free

2017-07-27T22:10:08+00:00

commit 8e6882545d8c06f99e9e117741cc87f3338b0bef upstream.

Dereferencing shost from scsi_exit_rq() is not safe because the SCSI
host may already have been freed when scsi_exit_rq() is called.
Increasing the shost reference count in scsi_init_rq() and dropping that
reference in scsi_exit_rq() is nontrivial since scsi_host_dev_release()
may sleep and since scsi_exit_rq() may be called from interrupt
context. Since scsi_exit_rq() only needs a single bit from shost, copy
that bit into struct scsi_cmnd.

Reported-by: Scott Bauer 
Fixes: e9c787e65c0c ("scsi: allocate scsi_cmnd structures as part of struct request")
Signed-off-by: Bart Van Assche 
Reviewed-by: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Scott Bauer 
Cc: Jan Kara 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: Add STARGET_CREATED_REMOVE state to scsi_target_state

2017-07-27T22:10:07+00:00

commit f9279c968c257ee39b0d7bd2571a4d231a67bcc1 upstream.

The addition of the STARGET_REMOVE state had the side effect of
introducing a race condition that can cause a crash.

scsi_target_reap_ref_release() checks the starget->state to
see if it still in STARGET_CREATED, and if so, skips calling
transport_remove_device() and device_del(), because the starget->state
is only set to STARGET_RUNNING after scsi_target_add() has called
device_add() and transport_add_device().

However, if an rport loss occurs while a target is being scanned,
it can happen that scsi_remove_target() will be called while the
starget is still in the STARGET_CREATED state.  In this case, the
starget->state will be set to STARGET_REMOVE, and as a result,
scsi_target_reap_ref_release() will take the wrong path.  The end
result is a panic:

[ 1255.356653] Oops: 0000 [#1] SMP
[ 1255.360154] Modules linked in: x86_pkg_temp_thermal kvm_intel kvm irqbypass crc32c_intel ghash_clmulni_i
[ 1255.393234] CPU: 5 PID: 149 Comm: kworker/u96:4 Tainted: G        W       4.11.0+ #8
[ 1255.401879] Hardware name: Dell Inc. PowerEdge R320/08VT7V, BIOS 2.0.22 11/19/2013
[ 1255.410327] Workqueue: scsi_wq_6 fc_scsi_scan_rport [scsi_transport_fc]
[ 1255.417720] task: ffff88060ca8c8c0 task.stack: ffffc900048a8000
[ 1255.424331] RIP: 0010:kernfs_find_ns+0x13/0xc0
[ 1255.429287] RSP: 0018:ffffc900048abbf0 EFLAGS: 00010246
[ 1255.435123] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 1255.443083] RDX: 0000000000000000 RSI: ffffffff8188d659 RDI: 0000000000000000
[ 1255.451043] RBP: ffffc900048abc10 R08: 0000000000000000 R09: 0000012433fe0025
[ 1255.459005] R10: 0000000025e5a4b5 R11: 0000000025e5a4b5 R12: ffffffff8188d659
[ 1255.466972] R13: 0000000000000000 R14: ffff8805f55e5088 R15: 0000000000000000
[ 1255.474931] FS:  0000000000000000(0000) GS:ffff880616b40000(0000) knlGS:0000000000000000
[ 1255.483959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1255.490370] CR2: 0000000000000068 CR3: 0000000001c09000 CR4: 00000000000406e0
[ 1255.498332] Call Trace:
[ 1255.501058]  kernfs_find_and_get_ns+0x31/0x60
[ 1255.505916]  sysfs_unmerge_group+0x1d/0x60
[ 1255.510498]  dpm_sysfs_remove+0x22/0x60
[ 1255.514783]  device_del+0xf4/0x2e0
[ 1255.518577]  ? device_remove_file+0x19/0x20
[ 1255.523241]  attribute_container_class_device_del+0x1a/0x20
[ 1255.529457]  transport_remove_classdev+0x4e/0x60
[ 1255.534607]  ? transport_add_class_device+0x40/0x40
[ 1255.540046]  attribute_container_device_trigger+0xb0/0xc0
[ 1255.546069]  transport_remove_device+0x15/0x20
[ 1255.551025]  scsi_target_reap_ref_release+0x25/0x40
[ 1255.556467]  scsi_target_reap+0x2e/0x40
[ 1255.560744]  __scsi_scan_target+0xaa/0x5b0
[ 1255.565312]  scsi_scan_target+0xec/0x100
[ 1255.569689]  fc_scsi_scan_rport+0xb1/0xc0 [scsi_transport_fc]
[ 1255.576099]  process_one_work+0x14b/0x390
[ 1255.580569]  worker_thread+0x4b/0x390
[ 1255.584651]  kthread+0x109/0x140
[ 1255.588251]  ? rescuer_thread+0x330/0x330
[ 1255.592730]  ? kthread_park+0x60/0x60
[ 1255.596815]  ret_from_fork+0x29/0x40
[ 1255.600801] Code: 24 08 48 83 42 40 01 5b 41 5c 5d c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90
[ 1255.621876] RIP: kernfs_find_ns+0x13/0xc0 RSP: ffffc900048abbf0
[ 1255.628479] CR2: 0000000000000068
[ 1255.632756] ---[ end trace 34a69ba0477d036f ]---

Fix this by adding another scsi_target state STARGET_CREATED_REMOVE
to distinguish this case.

Fixes: f05795d3d771 ("scsi: Add intermediate STARGET_REMOVE state to scsi_target_state")
Reported-by: David Jeffery 
Signed-off-by: Ewan D. Milne 
Reviewed-by: Laurence Oberman 
Tested-by: Laurence Oberman 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: Allow ABTS, PURX, RIDA on ATIOQ for ISP83XX/27XX

2017-07-27T22:10:07+00:00

commit 3c4810ffdc8e4f34d387f59baf0abefcfa4ada6a upstream.

Driver added mechanism to move ABTS/PUREX/RIDA mailbox to
ATIO queue as part of commit id 41dc529a4602ac737020f423f84686a81de38e6d
("qla2xxx: Improve RSCN handling in driver").

This patch adds a check to only allow ABTS/PURX/RIDA
to be moved to ATIO Queue for ISP83XX and ISP27XX.

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: virtio_scsi: let host do exception handling

2017-07-27T22:10:07+00:00

commit e72c9a2a67a6400c8ef3d01d4c461dbbbfa0e1f0 upstream.

virtio_scsi tries to do exception handling after the default 30 seconds
timeout expires.  However, it's better to let the host control the
timeout, otherwise with a heavy I/O load it is likely that an abort will
also timeout.  This leads to fatal errors like filesystems going
offline.

Disable the 'sd' timeout and allow the host to do exception handling,
following the precedent of the storvsc driver.

Hannes has a proposal to introduce timeouts in virtio, but this provides
an immediate solution for stable kernels too.

[mkp: fixed typo]

Reported-by: Douglas Miller 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Cc: Hannes Reinecke 
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2017-06-23T19:25:37+00:00

Pull SCSI fixes from James Bottomley:
 "Two fixes to remove spurious WARN_ONs from the new(ish) qedi driver.

  The driver already prints a warning message, there's no need to panic
  users by printing something that looks like an oops as well"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: qedi: Remove WARN_ON from clear task context.
  scsi: qedi: Remove WARN_ON for untracked cleanup.

scsi: qedi: Remove WARN_ON from clear task context.

2017-06-20T01:53:42+00:00

Signed-off-by: Manish Rangankar 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen

scsi: qedi: Remove WARN_ON for untracked cleanup.

2017-06-20T01:53:36+00:00

Signed-off-by: Manish Rangankar 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen