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

drivers/scsi/sg.c: mark VMA as VM_IO to prevent migration

2016-02-15T20:42:38+00:00

[ Upstream commit 461c7fa126794157484dca48e88effa4963e3af3 ]

Reduced testcase:

    #include 
    #include 
    #include 
    #include 

    #define SIZE 0x2000

    int main()
    {
        int fd;
        void *p;

        fd = open("/dev/sg0", O_RDWR);
        p = mmap(NULL, SIZE, PROT_EXEC, MAP_PRIVATE | MAP_LOCKED, fd, 0);
        mbind(p, SIZE, 0, NULL, 0, MPOL_MF_MOVE);
        return 0;
    }

We shouldn't try to migrate pages in sg VMA as we don't have a way to
update Sg_scatter_hold::pages accordingly from mm core.

Let's mark the VMA as VM_IO to indicate to mm core that the VMA is not
migratable.

Signed-off-by: Kirill A. Shutemov 
Reported-by: Dmitry Vyukov 
Acked-by: Vlastimil Babka 
Cc: Doug Gilbert 
Cc: David Rientjes 
Cc: Naoya Horiguchi 
Cc: "Kirill A. Shutemov" 
Cc: Shiraz Hashim 
Cc: Hugh Dickins 
Cc: Sasha Levin 
Cc: syzkaller 
Cc: Kostya Serebryany 
Cc: Alexander Potapenko 
Cc: James Bottomley 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

SCSI: fix crashes in sd and sr runtime PM

2016-02-15T20:42:32+00:00

[ Upstream commit 13b4389143413a1f18127c07f72c74cad5b563e8 ]

Runtime suspend during driver probe and removal can cause problems.
The driver's runtime_suspend or runtime_resume callbacks may invoked
before the driver has finished binding to the device or after the
driver has unbound from the device.

This problem shows up with the sd and sr drivers, and can cause disk
or CD/DVD drives to become unusable as a result.  The fix is simple.
The drivers store a pointer to the scsi_disk or scsi_cd structure as
their private device data when probing is finished, so we simply have
to be sure to clear the private data during removal and test it during
runtime suspend/resume.

This fixes .

Signed-off-by: Alan Stern 
Reported-by: Paul Menzel 
Reported-by: Erich Schubert 
Reported-by: Alexandre Rossi 
Tested-by: Paul Menzel 
Tested-by: Erich Schubert 
CC: 
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

mvsas: Fix NULL pointer dereference in mvs_slot_task_free

2015-11-15T17:51:52+00:00

[ Upstream commit 2280521719e81919283b82902ac24058f87dfc1b ]

When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
NULL but it's later used in mvs_abort_task as slot which is passed
to mvs_slot_task_free causing NULL pointer dereference.

Just return from mvs_slot_task_free when passed with NULL slot.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891
Signed-off-by: Dāvis Mosāns 
Reviewed-by: Tomas Henzl 
Reviewed-by: Johannes Thumshirn 
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley 
Signed-off-by: Sasha Levin

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