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

scsi: sd: Do not override max_sectors_kb sysfs setting

2017-10-12T09:56:18+00:00

commit 77082ca503bed061f7fbda7cfd7c93beda967a41 upstream.

A user may lower the max_sectors_kb setting in sysfs to accommodate
certain workloads. Previously we would always set the max I/O size to
either the block layer default or the optional preferred I/O size
reported by the device.

Keep the current heuristics for the initial setting of max_sectors_kb.
For subsequent invocations, only update the current queue limit if it
exceeds the capabilities of the hardware.

Reported-by: Don Brace 
Reviewed-by: Martin Wilck 
Tested-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP

2017-10-12T09:56:18+00:00

commit 28a0bc4120d38a394499382ba21d6965a67a3703 upstream.

SBC-4 states:

  "A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates the
   maximum number of LBAs that may be unmapped by an UNMAP command"

  "A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates
   the maximum number of contiguous logical blocks that the device server
   allows to be unmapped or written in a single WRITE SAME command."

Despite the spec being clear on the topic, some devices incorrectly
expect WRITE SAME commands with the UNMAP bit set to be limited to the
value reported in MAXIMUM UNMAP LBA COUNT in the Block Limits VPD.

Implement a blacklist option that can be used to accommodate devices
with this behavior.

Reported-by: Bill Kuzeja 
Reported-by: Ewan D. Milne 
Reviewed-by: Ewan D. Milne 
Tested-by: Laurence Oberman 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Add a small delay after IOP reset

2017-10-05T07:47:27+00:00

commit d1b490939d8c117a06dfc562c41d933f71d30289 upstream.

Commit 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset
status") changed the way driver checks if a reset succeeded. Now, after an
IOP reset, aacraid immediately start polling a register to verify the reset
is complete.

This behavior cause regressions on the reset path in PowerPC (at least).
Since the delay after the IOP reset was removed by the aforementioned patch,
the fact driver just starts to read a register instantly after the reset
was issued (by writing in another register) "corrupts" the reset procedure,
which ends up failing all the time.

The issue highly impacted kdump on PowerPC, since on kdump path we
proactively issue a reset in adapter (through the reset_devices kernel
parameter).

This patch (re-)adds a delay right after IOP reset is issued. Empirically
we measured that 3 seconds is enough, but for safety reasons we delay
for 5s (and since it was 30s before, 5s is still a small amount).

For reference, without this patch we observe the following messages
on kdump kernel boot process:

  [ 76.294] aacraid 0003:01:00.0: IOP reset failed
  [ 76.294] aacraid 0003:01:00.0: ARC Reset attempt failed
  [ 86.524] aacraid 0003:01:00.0: adapter kernel panic'd ff.
  [ 86.524] aacraid 0003:01:00.0: Controller reset type is 3
  [ 86.524] aacraid 0003:01:00.0: Issuing IOP reset
  [146.534] aacraid 0003:01:00.0: IOP reset failed
  [146.534] aacraid 0003:01:00.0: ARC Reset attempt failed

Fixes: 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset status")
Signed-off-by: Guilherme G. Piccoli 
Acked-by: Dave Carroll 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Fix 2T+ drives on SmartIOC-2000

2017-10-05T07:47:27+00:00

commit 6c92f7dbf25c36f35320e4ae0b508676410bac04 upstream.

The logic for supporting large drives was previously tied to 4Kn support
for SmartIOC-2000. As SmartIOC-2000 does not support volumes using 4Kn
drives, use the intended option flag AAC_OPT_NEW_COMM_64 to determine
support for volumes greater than 2T.

Signed-off-by: Dave Carroll 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Raghava Aditya Renukunta 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly

2017-10-05T07:47:27+00:00

commit c88f0e6b06f4092995688211a631bb436125d77b upstream.

ChunYu found a kernel crash by syzkaller:

[  651.617875] kasan: CONFIG_KASAN_INLINE enabled
[  651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access
[  651.618731] general protection fault: 0000 [#1] SMP KASAN
[  651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32
[  651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[  651.622309] task: ffff880117780000 task.stack: ffff8800a3188000
[  651.622762] RIP: 0010:skb_release_data+0x26c/0x590
[...]
[  651.627260] Call Trace:
[  651.629156]  skb_release_all+0x4f/0x60
[  651.629450]  consume_skb+0x1a5/0x600
[  651.630705]  netlink_unicast+0x505/0x720
[  651.632345]  netlink_sendmsg+0xab2/0xe70
[  651.633704]  sock_sendmsg+0xcf/0x110
[  651.633942]  ___sys_sendmsg+0x833/0x980
[  651.637117]  __sys_sendmsg+0xf3/0x240
[  651.638820]  SyS_sendmsg+0x32/0x50
[  651.639048]  entry_SYSCALL_64_fastpath+0x1f/0xc2

It's caused by skb_shared_info at the end of sk_buff was overwritten by
ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx.

During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh),
ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a
new value to skb_shinfo(SKB)->nr_frags by ev->type.

This patch is to fix it by checking nlh->nlmsg_len properly there to
avoid over accessing sk_buff.

Reported-by: ChunYu Wang 
Signed-off-by: Xin Long 
Acked-by: Chris Leech 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: scsi_transport_fc: fix NULL pointer dereference in fc_bsg_job_timeout

2017-10-05T07:47:25+00:00

commit b468b6a4969f9bdddb31d484f151bfa03fbee767 upstream.

bsg-lib now embeddeds the job structure into the request, and
req->special can't be used anymore.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ming Lei 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: Fix an integer overflow in sysfs code

2017-09-27T12:43:18+00:00

commit e6f77540c067b48dee10f1e33678415bfcc89017 upstream.

The value of "size" comes from the user.  When we add "start + size" it
could lead to an integer overflow bug.

It means we vmalloc() a lot more memory than we had intended.  I believe
that on 64 bit systems vmalloc() can succeed even if we ask it to
allocate huge 4GB buffers.  So we would get memory corruption and likely
a crash when we call ha->isp_ops->write_optrom() and ->read_optrom().

Only root can trigger this bug.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=194061

Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.")
Reported-by: shqking 
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: Use fabric name for Get Port Speed command

2017-09-27T12:43:18+00:00

commit b2e8ae3f0e342a3308b4573790bd42528e51885a upstream.

The Get Port Speed switch command needs the fabric port name of the
remote device.  Current code uses the registered WWPN.

Fixes: 726b85487067d ("qla2xxx: Add framework for async fabric discovery")
Cc:  # 4.10+
Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: Use BIT_6 to acquire FAWWPN from switch

2017-09-27T12:43:18+00:00

commit fcc5b5cd726c0779cd689362aea82cc9d5a61346 upstream.

If FA-WWPN feature disabled on the switch side and enabled for the
adapter, then driver would update the port name with switch port name.

This patch fixes issue by checking correct BIT flag to validate.

Fixes: 41dc529a4602 ("qla2xxx: Improve RSCN handling in driver")
Signed-off-by: Sawan Chandak 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: Fix target multiqueue configuration

2017-09-27T12:43:18+00:00

commit b7edfa235effb4b4a9816c2345620b11609c123e upstream.

Following error will be logged in to message file while trying to
configure target with multiqueue.

"Cmd 0x1f aborted with timeout since ISP Abort is pending"
"qla25xx_init_queues Rsp que: 1 init failed."

Fixes: 82de802ad46e ("scsi: qla2xxx: Preparation for Target MQ.")
Signed-off-by: Quinn Tran 
Signed-off-by: Michael Hernandez 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman