linux-stable.git/drivers/scsi, branch linux-3.4.y

ses: fix additional element traversal bug

2016-10-26T15:15:37+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: Zefan Li

ses: Fix problems with simple enclosures

2016-10-26T15:15:36+00:00

commit 3417c1b5cb1fdc10261dbed42b05cc93166a78fd upstream.

Simple enclosure implementations (mostly USB) are allowed to return only
page 8 to every diagnostic query.  That really confuses our
implementation because we assume the return is the page we asked for and
end up doing incorrect offsets based on bogus information leading to
accesses outside of allocated ranges.  Fix that by checking the page
code of the return and giving an error if it isn't the one we asked for.
This should fix reported bugs with USB storage by simply refusing to
attach to enclosures that behave like this.  It's also good defensive
practise now that we're starting to see more USB enclosures.

Reported-by: Andrea Gelmini 
Reviewed-by: Ewan D. Milne 
Reviewed-by: Tomas Henzl 
Signed-off-by: James Bottomley 
Signed-off-by: Zefan Li

scsi_sysfs: Fix queue_ramp_up_period return code

2016-10-26T15:15:28+00:00

commit 863e02d0e173bb9d8cea6861be22820b25c076cc upstream.

Writing a number to /sys/bus/scsi/devices//queue_ramp_up_period
returns the value of that number instead of the number of bytes written.
This behavior can confuse programs expecting POSIX write() semantics.
Fix this by returning the number of bytes written instead.

Signed-off-by: Peter Oberparleiter 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Matthew R. Ochs 
Reviewed-by: Ewan D. Milne 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Zefan Li

megaraid_sas : SMAP restriction--do not access user memory from IOCTL code

2016-10-26T15:15:27+00:00

commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.

This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
OS. Do not access user memory from kernel code. The SMAP bit restricts
accessing user memory from kernel code.

Signed-off-by: Sumit Saxena 
Signed-off-by: Kashyap Desai 
Reviewed-by: Tomas Henzl 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Zefan Li

megaraid_sas: Do not use PAGE_SIZE for max_sectors

2016-10-26T15:15:26+00:00

commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 upstream.

Do not use PAGE_SIZE marco to calculate max_sectors per I/O
request. Driver code assumes PAGE_SIZE will be always 4096 which can
lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue
was reported in Ubuntu Bugzilla Bug #1475166.

Signed-off-by: Sumit Saxena 
Signed-off-by: Kashyap Desai 
Reviewed-by: Tomas Henzl 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Zefan Li

scsi: restart list search after unlock in scsi_remove_target

2016-10-26T15:15:24+00:00

commit 40998193560dab6c3ce8d25f4fa58a23e252ef38 upstream.

When dropping a lock while iterating a list we must restart the search
as other threads could have manipulated the list under us.  Without this
we can get stuck in an endless loop.  This bug was introduced by

commit bc3f02a795d3b4faa99d37390174be2a75d091bd
Author: Dan Williams 
Date:   Tue Aug 28 22:12:10 2012 -0700

    [SCSI] scsi_remove_target: fix softlockup regression on hot remove

Which was itself trying to fix a reported soft lockup issue

http://thread.gmane.org/gmane.linux.kernel/1348679

However, we believe even with this revert of the original patch, the soft
lockup problem has been fixed by

commit f2495e228fce9f9cec84367547813cbb0d6db15a
Author: James Bottomley 
Date:   Tue Jan 21 07:01:41 2014 -0800

    [SCSI] dual scan thread bug fix

Thanks go to Dan Williams  for tracking all this
prior history down.

Reported-by: Johannes Thumshirn 
Signed-off-by: Christoph Hellwig 
Tested-by: Johannes Thumshirn 
Reviewed-by: Johannes Thumshirn 
Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd
Signed-off-by: James Bottomley 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

mvsas: Fix NULL pointer dereference in mvs_slot_task_free

2016-04-27T10:55:29+00:00

commit 2280521719e81919283b82902ac24058f87dfc1b upstream.

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 
Signed-off-by: James Bottomley 
Signed-off-by: Zefan Li

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

2016-03-21T01:17:54+00:00

commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream.

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)
Signed-off-by: Al Viro 
[lizf: Backported to 3.4: s/MAX_UIOVEC/UIO_MAXIOV]
Signed-off-by: Zefan Li

libfc: Fix fc_fcp_cleanup_each_cmd()

2016-03-21T01:17:52+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: Zefan Li

libiscsi: Fix host busy blocking during connection teardown

2016-03-21T01:17:52+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 
[lizf: Backported to 3.4: adjust context]
Signed-of-by: Zefan Li