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

aacraid: Fix for aac_command_thread hang

2016-06-08T00:21:57+00:00

commit fc4bf75ea300a5e62a2419f89dd0e22189dd7ab7 upstream.

Typically under error conditions, it is possible for aac_command_thread()
to miss the wakeup from kthread_stop() and go back to sleep, causing it
to hang aac_shutdown.

In the observed scenario, the adapter is not functioning correctly and so
aac_fib_send() never completes (or time-outs depending on how it was
called). Shortly after aac_command_thread() starts it performs
aac_fib_send(SendHostTime) which hangs. When aac_probe_one
/aac_get_adapter_info send time outs, kthread_stop is called which breaks
the command thread out of it's hang.

The code will still go back to sleep in schedule_timeout() without
checking kthread_should_stop() so it causes aac_probe_one to hang until
the schedule_timeout() which is 30 minutes.

Fixed by: Adding another kthread_should_stop() before schedule_timeout()
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

aacraid: Relinquish CPU during timeout wait

2016-06-08T00:21:57+00:00

commit 07beca2be24cc710461c0b131832524c9ee08910 upstream.

aac_fib_send has a special function case for initial commands during
driver initialization using wait < 0(pseudo sync mode). In this case,
the command does not sleep but rather spins checking for timeout.This
loop is calls cpu_relax() in an attempt to allow other processes/threads
to use the CPU, but this function does not relinquish the CPU and so the
command will hog the processor. This was observed in a KDUMP
"crashkernel" and that prevented the "command thread" (which is
responsible for completing the command from being timed out) from
starting because it could not get the CPU.

Fixed by replacing "cpu_relax()" call with "schedule()"
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

lpfc: fix misleading indentation

2016-05-11T09:21:00+00:00

commit aeb6641f8ebdd61939f462a8255b316f9bfab707 upstream.

gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array()
call in lpfc_online(), which clearly doesn't look right:

drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online':
drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
   lpfc_destroy_vport_work_array(phba, vports);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not
  if (vports != NULL)
  ^~

Looking at the patch that introduced this code, it's clear that the
behavior is correct and the indentation is wrong.

This fixes the indentation and adds curly braces around the previous
if() block for clarity, as that is most likely what caused the code
to be misindented in the first place.

Signed-off-by: Arnd Bergmann 
Fixes: 549e55cd2a1b ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list")
Reviewed-by: Sebastian Herbszt 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

ipr: Fix regression when loading firmware

2016-04-12T16:12:47+00:00

commit 21b81716c6bff24cda52dc75588455f879ddbfe9 upstream.

Commit d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite") removed
the end of line handling when storing the update_fw sysfs attribute.
This changed the userpace API because it started refusing writes
terminated by a line feed, which broke the update tools we already have.

This patch re-adds that handling, so both a write terminated by a line
feed or not can make it through with the update.

Fixes: d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite")
Signed-off-by: Gabriel Krisman Bertazi 
Cc: Insu Yun 
Acked-by: Brian King 
Signed-off-by: Martin K. Petersen 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

ipr: Fix out-of-bounds null overwrite

2016-04-12T16:12:47+00:00

commit d63c7dd5bcb9441af0526d370c43a65ca2c980d9 upstream.

Return value of snprintf is not bound by size value, 2nd argument.
(https://www.kernel.org/doc/htmldocs/kernel-api/API-snprintf.html).
Return value is number of printed chars, can be larger than 2nd
argument.  Therefore, it can write null byte out of bounds ofbuffer.
Since snprintf puts null, it does not need to put additional null byte.

Signed-off-by: Insu Yun 
Reviewed-by: Shane Seymour 
Signed-off-by: Martin K. Petersen 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

be2iscsi: set the boot_kset pointer to NULL in case of failure

2016-04-12T16:12:40+00:00

commit 84bd64993f916bcf86270c67686ecf4cea7b8933 upstream.

In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.

Signed-off-by: Maurizio Lombardi 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Jitendra Bhivare 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

aacraid: Fix memory leak in aac_fib_map_free

2016-04-12T16:12:39+00:00

commit f88fa79a61726ce9434df9b4aede36961f709f17 upstream.

aac_fib_map_free() calls pci_free_consistent() without checking that
dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are
indeed NULL/0, this will result in a hang as pci_free_consistent() will
attempt to invalidate cache for the entire 64-bit address space
(which would take a very long time).

Fixed by adding a check to make sure that dev->hw_fib_va and
dev->max_fib_size are not NULL and 0 respectively.

Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: Johannes Thumshirn 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

sg: fix dxferp in from_to case

2016-04-12T16:12:39+00:00

commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 upstream.

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Signed-off-by: Douglas Gilbert 
Reviewed-by: Ewan Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

target: Add TFO->abort_task for aborted task resources release

2016-03-09T23:33:28+00:00

commit 131e6abc674edb9f9a59090bb35bf6650569b7e7 upstream.

Now that TASK_ABORTED status is not generated for all cases by
TMR ABORT_TASK + LUN_RESET, a new TFO->abort_task() caller is
necessary in order to give fabric drivers a chance to unmap
hardware / software resources before the se_cmd descriptor is
released via the normal TFO->release_cmd() codepath.

This patch adds TFO->aborted_task() in core_tmr_abort_task()
in place of the original transport_send_task_abort(), and
also updates all fabric drivers to implement this caller.

The fabric drivers that include changes to perform cleanup
via ->aborted_task() are:

  - iscsi-target
  - iser-target
  - srpt
  - tcm_qla2xxx

The fabric drivers that currently set ->aborted_task() to
NOPs are:

  - loopback
  - tcm_fc
  - usb-gadget
  - sbp-target
  - vhost-scsi

For the latter five, there appears to be no additional cleanup
required before invoking TFO->release_cmd() to release the
se_cmd descriptor.

v2 changes:
  - Move ->aborted_task() call into transport_cmd_finish_abort (Alex)

Cc: Alex Leung 
Cc: Mark Rustad 
Cc: Roland Dreier 
Cc: Vu Pham 
Cc: Chris Boot 
Cc: Sebastian Andrzej Siewior 
Cc: Michael S. Tsirkin 
Cc: Giridhar Malavali 
Cc: Saurav Kashyap 
Cc: Quinn Tran 
Cc: Sagi Grimberg 
Cc: Or Gerlitz 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

ses: fix additional element traversal bug

2016-03-03T23:06:50+00:00

commit 5e1033561da1152c57b97ee84371dba2b3d64c25 upstream.

KASAN found that our additional element processing scripts drop off
the end of the VPD page into unallocated space.  The reason is that
not every element has additional information but our traversal
routines think they do, leading to them expecting far more additional
information than is present.  Fix this by adding a gate to the
traversal routine so that it only processes elements that are expected
to have additional information (list is in SES-2 section 6.1.13.1:
Additional Element Status diagnostic page overview)

Reported-by: Pavel Tikhomirov 
Tested-by: Pavel Tikhomirov 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman