linux-toradex.git/drivers/scsi, branch v3.18.23

3w-9xxx: don't unmap bounce buffered commands

2015-10-28T07:52:26+00:00

[ Upstream commit 15e3d5a285ab9283136dba34bbf72886d9146706 ]

3w controller don't dma map small single SGL entry commands but instead
bounce buffer them.  Add a helper to identify these commands and don't
call scsi_dma_unmap for them.

Based on an earlier patch from James Bottomley.

Fixes: 118c85 ("3w-9xxx: fix command completion race")
Reported-by: Tóth Attila 
Tested-by: Tóth Attila 
Signed-off-by: Christoph Hellwig 
Acked-by: Adam Radford 
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

scsi: fix scsi_error_handler vs. scsi_host_dev_release race

2015-10-28T02:12:53+00:00

[ Upstream commit 537b604c8b3aa8b96fe35f87dd085816552e294c ]

b9d5c6b7ef57 ("[SCSI] cleanup setting task state in
scsi_error_handler()") has introduced a race between scsi_error_handler
and scsi_host_dev_release resulting in the hang when the device goes
away because scsi_error_handler might miss a wake up:

CPU0					CPU1
scsi_error_handler			scsi_host_dev_release
  					  kthread_stop()
  kthread_should_stop()
    test_bit(KTHREAD_SHOULD_STOP)
					    set_bit(KTHREAD_SHOULD_STOP)
					    wake_up_process()
					    wait_for_completion()

  set_current_state(TASK_INTERRUPTIBLE)
  schedule()

The most straightforward solution seems to be to invert the ordering of
the set_current_state and kthread_should_stop.

The issue has been noticed during reboot test on a 3.0 based kernel but
the current code seems to be affected in the same way.

[jejb: additional comment added]
Cc:  # 3.6+
Reported-and-debugged-by: Mike Mayer 
Signed-off-by: Michal Hocko 
Reviewed-by: Dan Williams 
Reviewed-by: Hannes Reinecke 
Signed-off-by: James Bottomley 

Signed-off-by: Sasha Levin

lpfc: Fix scsi prep dma buf error.

2015-09-28T22:57:02+00:00

[ Upstream commit 5116fbf136ea21b8678a85eee5c03508736ada9f ]

Didn't check for less-than-or-equal zero. Means we may later call
scsi_dma_unmap() even though we don't have valid mappings.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

SCSI: Fix NULL pointer dereference in runtime PM

2015-09-27T16:18:51+00:00

[ Upstream commit 49718f0fb8c9af192b33d8af3a2826db04025371 ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

sd: Fix maximum I/O size for BLOCK_PC requests

2015-09-17T05:30:44+00:00

[ Upstream commit 4f258a46346c03fa0bbb6199ffaf4e1f9f599660 ]

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 
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

libiscsi: Fix host busy blocking during connection teardown

2015-09-17T05:30:30+00:00

[ Upstream commit 660d0831d1494a6837b2f810d08b5be092c1f31d ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

libfc: Fix fc_fcp_cleanup_each_cmd()

2015-09-16T14:02:51+00:00

[ Upstream commit 8f2777f53e3d5ad8ef2a176a4463a5c8e1a16431 ]

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 
Cc: stable 
Signed-off-by: Vasu Dev 
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

libfc: Fix fc_exch_recv_req() error path

2015-09-16T14:02:34+00:00

[ Upstream commit f6979adeaab578f8ca14fdd32b06ddee0d9d3314 ]

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 
Cc: stable 
Signed-off-by: Vasu Dev 
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

hpsa: fix a couple pci id table mistakes

2015-08-27T17:25:58+00:00

[ Upstream commit 7d2cce58a765e802959471f8a7edd83f113ad637 ]

Fix a couple of pci id table mistakes:
Subdevice ID 0x3323 missing from product[] table
	(another name for HP Smart Storage 1210m)
Bogus 0x1925 subdevice id removed from hpsa_pci_device_id[] (no such thing.)

Signed-off-by: Don Brace 
Reviewed-by: Webb Scales 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Sasha Levin

sg_start_req(): make sure that there's not too many elements in iovec

2015-08-27T17:25:54+00:00

[ Upstream commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 ]

unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there.  If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.

X-Coverup: TINC (and there's no lumber cartel either)
Cc: stable@vger.kernel.org # way, way back
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin