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

fnic: Use the local variable instead of I/O flag to acquire io_req_lock in fnic_queuecommand() to avoid deadloack

2015-09-13T16:07:51+00:00

commit db196935d9562abec4510f48d887bc1f1e054fcf upstream.

We added changes in fnic driver patch 1.6.0.16 to acquire
io_req_lock in fnic_queuecommand() before issuing I/O so that io completion
is serialized. But when releasing the lock we check for the I/O flag and
this could be modified if IO abort occurs before I/O completion. In this case
we wont release the lock and causes deadlock in some scenerios. Using the
local variable to check the IO lock status will resolve the problem.

Fixes: 41df7b02db82cf6c14f094757bac3830d10a827f
Signed-off-by: Hiral Shah 
Signed-off-by: Sesidhar Baddela 
Signed-off-by: Anil Chintalapati 
Reviewed-by: Martin K. Petersen 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

SCSI: Fix NULL pointer dereference in runtime PM

2015-09-13T16:07:51+00:00

commit 49718f0fb8c9af192b33d8af3a2826db04025371 upstream.

The routines in scsi_rpm.c assume that if a runtime-PM callback is
invoked for a SCSI device, it can only mean that the device's driver
has asked the block layer to handle the runtime power management (by
calling blk_pm_runtime_init(), which among other things sets q->dev).

However, this assumption turns out to be wrong for things like the ses
driver.  Normally ses devices are not allowed to do runtime PM, but
userspace can override this setting.  If this happens, the kernel gets
a NULL pointer dereference when blk_post_runtime_resume() tries to use
the uninitialized q->dev pointer.

This patch fixes the problem by calling the block layer's runtime-PM
routines only if the device's driver really does have a runtime-PM
callback routine.  Since ses doesn't define any such callbacks, the
crash won't occur.

This fixes Bugzilla #101371.

Signed-off-by: Alan Stern 
Reported-by: Stanisław Pitucha 
Reported-by: Ilan Cohen 
Tested-by: Ilan Cohen 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

Revert "libata-eh: Set 'information' field for autosense"

2015-09-13T16:07:46+00:00

commit fe16d4f202c59a560533a223bc6375739ee30944 upstream.

This reverts commit a1524f226a02aa6edebd90ae0752e97cfd78b159.

As implemented, ACS-4 sense reporting for ATA devices bypasses error
diagnosis and handling in libata degrading EH behavior significantly.
Revert the related changes for now.

Signed-off-by: Tejun Heo 
Cc: Hannes Reinecke 
Signed-off-by: Greg Kroah-Hartman

sd: Fix maximum I/O size for BLOCK_PC requests

2015-09-13T16:07:45+00:00

commit 4f258a46346c03fa0bbb6199ffaf4e1f9f599660 upstream.

Commit bcdb247c6b6a ("sd: Limit transfer length") clamped the maximum
size of an I/O request to the MAXIMUM TRANSFER LENGTH field in the BLOCK
LIMITS VPD. This had the unfortunate effect of also limiting the maximum
size of non-filesystem requests sent to the device through sg/bsg.

Avoid using blk_queue_max_hw_sectors() and set the max_sectors queue
limit directly.

Also update the comment in blk_limits_max_hw_sectors() to clarify that
max_hw_sectors defines the limit for the I/O controller only.

Signed-off-by: Martin K. Petersen 
Reported-by: Brian King 
Tested-by: Brian King 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

libiscsi: Fix host busy blocking during connection teardown

2015-09-13T16:07:45+00:00

commit 660d0831d1494a6837b2f810d08b5be092c1f31d upstream.

In case of hw iscsi offload, an host can have N-number of active
connections. There can be IO's running on some connections which
make host->host_busy always TRUE. Now if logout from a connection
is tried then the code gets into an infinite loop as host->host_busy
is always TRUE.

 iscsi_conn_teardown(....)
 {
   .........
    /*
     * Block until all in-progress commands for this connection
     * time out or fail.
     */
     for (;;) {
      spin_lock_irqsave(session->host->host_lock, flags);
      if (!atomic_read(&session->host->host_busy)) { /* OK for ERL == 0 */
	      spin_unlock_irqrestore(session->host->host_lock, flags);
              break;
      }
     spin_unlock_irqrestore(session->host->host_lock, flags);
     msleep_interruptible(500);
     iscsi_conn_printk(KERN_INFO, conn, "iscsi conn_destroy(): "
                 "host_busy %d host_failed %d\n",
	          atomic_read(&session->host->host_busy),
	          session->host->host_failed);

	................
	...............
     }
  }

This is not an issue with software-iscsi/iser as each cxn is a separate
host.

Fix:
Acquiring eh_mutex in iscsi_conn_teardown() before setting
session->state = ISCSI_STATE_TERMINATE.

Signed-off-by: John Soni Jose 
Reviewed-by: Mike Christie 
Reviewed-by: Chris Leech 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

libfc: Fix fc_fcp_cleanup_each_cmd()

2015-09-13T16:07:42+00:00

commit 8f2777f53e3d5ad8ef2a176a4463a5c8e1a16431 upstream.

Since fc_fcp_cleanup_cmd() can sleep this function must not
be called while holding a spinlock. This patch avoids that
fc_fcp_cleanup_each_cmd() triggers the following bug:

BUG: scheduling while atomic: sg_reset/1512/0x00000202
1 lock held by sg_reset/1512:
 #0:  (&(&fsp->scsi_pkt_lock)->rlock){+.-...}, at: [] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Preemption disabled at:[] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] __schedule_bug+0x6c/0xd0
 [] __schedule+0x71a/0xa10
 [] schedule+0x32/0x80
 [] fc_seq_set_resp+0xac/0x100 [libfc]
 [] fc_exch_done+0x41/0x60 [libfc]
 [] fc_fcp_cleanup_each_cmd.isra.21+0xcf/0x150 [libfc]
 [] fc_eh_device_reset+0x1c3/0x270 [libfc]
 [] scsi_try_bus_device_reset+0x29/0x60
 [] scsi_ioctl_reset+0x258/0x2d0
 [] scsi_ioctl+0x150/0x440
 [] sd_ioctl+0xad/0x120
 [] blkdev_ioctl+0x1b6/0x810
 [] block_ioctl+0x38/0x40
 [] do_vfs_ioctl+0x2f8/0x530
 [] SyS_ioctl+0x81/0xa0
 [] system_call_fastpath+0x16/0x7a

Signed-off-by: Bart Van Assche 
Signed-off-by: Vasu Dev 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

libfc: Fix fc_exch_recv_req() error path

2015-09-13T16:07:42+00:00

commit f6979adeaab578f8ca14fdd32b06ddee0d9d3314 upstream.

Due to patch "libfc: Do not invoke the response handler after
fc_exch_done()" (commit ID 7030fd62) the lport_recv() call
in fc_exch_recv_req() is passed a dangling pointer. Avoid this
by moving the fc_frame_free() call from fc_invoke_resp() to its
callers. This patch fixes the following crash:

general protection fault: 0000 [#3] PREEMPT SMP
RIP: fc_lport_recv_req+0x72/0x280 [libfc]
Call Trace:
 fc_exch_recv+0x642/0xde0 [libfc]
 fcoe_percpu_receive_thread+0x46a/0x5ed [fcoe]
 kthread+0x10a/0x120
 ret_from_fork+0x42/0x70

Signed-off-by: Bart Van Assche 
Signed-off-by: Vasu Dev 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

ipr: Fix invalid array indexing for HRRQ

2015-08-17T03:52:11+00:00

commit 3f1c0581310d5d94bd72740231507e763a6252a4 upstream.

Fixes another signed / unsigned array indexing bug in the ipr driver.
Currently, when hrrq_index wraps, it becomes a negative number. We
do the modulo, but still have a negative number, so we end up indexing
backwards in the array. Given where the hrrq array is located in memory,
we probably won't actually reference memory we don't own, but nonetheless
ipr is still looking at data within struct ipr_ioa_cfg and interpreting it as
struct ipr_hrr_queue data, so bad things could certainly happen.

Each ipr adapter has anywhere from 1 to 16 HRRQs. By default, we use 2 on new
adapters.  Let's take an example:

Assume ioa_cfg->hrrq_index=0x7fffffffe and ioa_cfg->hrrq_num=4:

The atomic_add_return will then return -1. We mod this with 3 and get -2, add
one and get -1 for an array index.

On adapters which support more than a single HRRQ, we dedicate HRRQ to adapter
initialization and error interrupts so that we can optimize the other queues
for fast path I/O. So all normal I/O uses HRRQ 1-15. So we want to spread the
I/O requests across those HRRQs.

With the default module parameter settings, this bug won't hit, only when
someone sets the ipr.number_of_msix parameter to a value larger than 3 is when
bad things start to happen.

Tested-by: Wen Xiong 
Reviewed-by: Wen Xiong 
Reviewed-by: Gabriel Krisman Bertazi 
Signed-off-by: Brian King 
Reviewed-by: Martin K. Petersen 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

ipr: Fix incorrect trace indexing

2015-08-17T03:52:10+00:00

commit bb7c54339e6a10ecce5c4961adf5e75b3cf0af30 upstream.

When ipr's internal driver trace was changed to an atomic, a signed/unsigned
bug slipped in which results in us indexing backwards in our memory buffer
writing on memory that does not belong to us. This patch fixes this by removing
the modulo and instead just mask off the low bits.

Tested-by: Wen Xiong 
Reviewed-by: Wen Xiong 
Reviewed-by: Gabriel Krisman Bertazi 
Signed-off-by: Brian King 
Reviewed-by: Martin K. Petersen 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

ipr: Fix locking for unit attention handling

2015-08-17T03:52:10+00:00

commit 36b8e180e1e929e00b351c3b72aab3147fc14116 upstream.

Make sure we have the host lock held when calling scsi_report_bus_reset. Fixes
a crash seen as the __devices list in the scsi host was changing as we were
iterating through it.

Reviewed-by: Wen Xiong 
Reviewed-by: Gabriel Krisman Bertazi 
Signed-off-by: Brian King 
Reviewed-by: Martin K. Petersen 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman