linux-stable.git/drivers/scsi, branch v3.12.72

scsi: lpfc: Correct WQ creation for pagesize

2017-03-13T20:40:41+00:00

commit 8ea73db486cda442f0671f4bc9c03a76be398a28 upstream.

Correct WQ creation for pagesize

The driver was calculating the adapter command pagesize indicator from
the system pagesize. However, the buffers the driver allocates are only
one size (SLI4_PAGE_SIZE), so no calculation was necessary.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen 
Cc: Mauricio Faria de Oliveira 
Signed-off-by: Jiri Slaby

sd: get disk reference in sd_check_events()

2017-03-13T20:40:28+00:00

commit eb72d0bb84eee5d0dc3044fd17b75e7101dabb57 upstream.

sd_check_events() is called asynchronously, and might race
with device removal. So always take a disk reference when
processing the event to avoid the device being removed while
the event is processed.

Signed-off-by: Hannes Reinecke 
Reviewed-by: Ewan D. Milne 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Cc: Jinpu Wang 
Signed-off-by: Jiri Slaby

scsi: aacraid: Reorder Adapter status check

2017-03-13T20:40:27+00:00

commit c421530bf848604e97d0785a03b3fe2c62775083 upstream.

The driver currently checks the SELF_TEST_FAILED first and then
KERNEL_PANIC next. Under error conditions(boot code failure) both
SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time.

The driver has the capability to reset the controller on an KERNEL_PANIC,
but not on SELF_TEST_FAILED.

Fixed by first checking KERNEL_PANIC and then the others.

Fixes: e8b12f0fb835223752 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC base controller family)
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: David Carroll 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Jiri Slaby

scsi: storvsc: properly set residual data length on errors

2017-03-13T20:40:27+00:00

commit 40630f462824ee24bc00d692865c86c3828094e0 upstream.

On I/O errors, the Windows driver doesn't set data_transfer_length
on error conditions other than SRB_STATUS_DATA_OVERRUN.
In these cases we need to set data_transfer_length to 0,
indicating there is no data transferred. On SRB_STATUS_DATA_OVERRUN,
data_transfer_length is set by the Windows driver to the actual data transferred.

Reported-by: Shiva Krishna 
Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Jiri Slaby

scsi: storvsc: properly handle SRB_ERROR when sense message is present

2017-03-13T20:40:26+00:00

commit bba5dc332ec2d3a685cb4dae668c793f6a3713a3 upstream.

When sense message is present on error, we should pass along to the upper
layer to decide how to deal with the error.
This patch fixes connectivity issues with Fiber Channel devices.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Jiri Slaby

scsi: storvsc: use tagged SRB requests if supported by the device

2017-03-13T20:40:25+00:00

commit 3cd6d3d9b1abab8dcdf0800224ce26daac24eea2 upstream.

Properly set SRB flags when hosting device supports tagged queuing.
This patch improves the performance on Fiber Channel disks.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Jiri Slaby

scsi: don't BUG_ON() empty DMA transfers

2017-03-01T09:38:14+00:00

commit fd3fc0b4d7305fa7246622dcc0dec69c42443f45 upstream.

Don't crash the machine just because of an empty transfer. Use WARN_ON()
combined with returning an error.

Found by Dmitry Vyukov and syzkaller.

[ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
  cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
  might still be a cause of excessive log spamming.

  NOTE! If this warning ever triggers, we may end up leaking resources,
  since this doesn't bother to try to clean the command up. So this
  WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
  much worse.

  People really need to stop using BUG_ON() for "this shouldn't ever
  happen". It makes pretty much any bug worse.     - Linus ]

Signed-off-by: Johannes Thumshirn 
Reported-by: Dmitry Vyukov 
Cc: James Bottomley 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby

scsi: move the nr_phys_segments assert into scsi_init_io

2017-03-01T09:31:19+00:00

commit 635d98b1d0cfc2ba3426a701725d31a6102c059a upstream.

scsi_init_io should only be called for requests that transfer data,
so move the assert that a request has segments from the callers into
scsi_init_io.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Jiri Slaby

sg: Fix double-free when drives detach during SG_IO

2017-01-27T16:14:58+00:00

commit f3951a3709ff50990bf3e188c27d346792103432 upstream.

In sg_common_write(), we free the block request and return -ENODEV if
the device is detached in the middle of the SG_IO ioctl().

Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
end up freeing rq->cmd in the already free rq object, and then free
the object itself out from under the current user.

This ends up corrupting random memory via the list_head on the rq
object. The most common crash trace I saw is this:

  ------------[ cut here ]------------
  kernel BUG at block/blk-core.c:1420!
  Call Trace:
  [] blk_put_request+0x5b/0x80
  [] sg_finish_rem_req+0x6b/0x120 [sg]
  [] sg_common_write.isra.14+0x459/0x5a0 [sg]
  [] ? selinux_file_alloc_security+0x48/0x70
  [] sg_new_write.isra.17+0x195/0x2d0 [sg]
  [] sg_ioctl+0x644/0xdb0 [sg]
  [] do_vfs_ioctl+0x90/0x520
  [] ? file_has_perm+0x97/0xb0
  [] SyS_ioctl+0x91/0xb0
  [] tracesys+0xdd/0xe2
    RIP [] __blk_put_request+0x154/0x1a0

The solution is straightforward: just set srp->rq to NULL in the
failure branch so that sg_finish_rem_req() doesn't attempt to re-free
it.

Additionally, since sg_rq_end_io() will never be called on the object
when this happens, we need to free memory backing ->cmd if it isn't
embedded in the object itself.

KASAN was extremely helpful in finding the root cause of this bug.

Signed-off-by: Calvin Owens 
Acked-by: Douglas Gilbert 
Signed-off-by: Martin K. Petersen 
Acked-by: Johannes Thumshirn 
Signed-off-by: Jiri Slaby

qla2xxx: Fix crash due to null pointer access

2017-01-26T16:41:04+00:00

commit fc1ffd6cb38a1c1af625b9833c41928039e733f5 upstream.

During code inspection, while investigating following stack trace
seen on one of the test setup, we found out there was possibility
of memory leak becuase driver was not unwinding the stack properly.

This issue has not been reproduced in a test environment or on a
customer setup.

Here's stack trace that was seen.

[1469877.797315] Call Trace:
[1469877.799940]  [] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
[1469877.806980]  [] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
[1469877.814013]  [] ? __pm_runtime_resume+0x51/0xa0
[1469877.820265]  [] ? _raw_spin_lock_irqsave+0x25/0x90
[1469877.826776]  [] ? _raw_spin_unlock_irqrestore+0x6d/0x80
[1469877.833720]  [] ? preempt_count_sub+0xb1/0x100
[1469877.839885]  [] ? _raw_spin_unlock_irqrestore+0x4c/0x80
[1469877.846830]  [] local_pci_probe+0x4c/0xb0
[1469877.852562]  [] ? preempt_count_sub+0xb1/0x100
[1469877.858727]  [] pci_call_probe+0x89/0xb0

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Reviewed-by: Christoph Hellwig 
[ bvanassche: Fixed spelling in patch description ]
Signed-off-by: Bart Van Assche 
Signed-off-by: Jiri Slaby