<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/scsi, branch v3.2.77</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>SCSI: initio: remove duplicate module device table</title>
<updated>2016-02-13T10:34:04+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2015-11-19T14:33:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=558c1f07308ed4bf6c74aa6432cce9f90cc0e221'/>
<id>558c1f07308ed4bf6c74aa6432cce9f90cc0e221</id>
<content type='text'>
commit d282e2b383e3f41a7758e8cbf3076091ef9d9447 upstream.

The initio driver has for many years had two copies of the
same module device table. One of them is also used for registering
the other driver, the other one is entirely useless after the
large scale cleanup that Alan Cox did back in 2007.

The compiler warns about this whenever the driver is built-in:

drivers/scsi/initio.c:131:29: warning: 'i91u_pci_devices' defined but not used [-Wunused-variable]

This removes the extraneous table and the warning.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Fixes: 72d39fea901 ("[SCSI] initio: Convert into a real Linux driver and update to modern style")
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d282e2b383e3f41a7758e8cbf3076091ef9d9447 upstream.

The initio driver has for many years had two copies of the
same module device table. One of them is also used for registering
the other driver, the other one is entirely useless after the
large scale cleanup that Alan Cox did back in 2007.

The compiler warns about this whenever the driver is built-in:

drivers/scsi/initio.c:131:29: warning: 'i91u_pci_devices' defined but not used [-Wunused-variable]

This removes the extraneous table and the warning.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Fixes: 72d39fea901 ("[SCSI] initio: Convert into a real Linux driver and update to modern style")
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ses: fix additional element traversal bug</title>
<updated>2016-01-22T21:40:04+00:00</updated>
<author>
<name>James Bottomley</name>
<email>James.Bottomley@HansenPartnership.com</email>
</author>
<published>2015-12-11T17:16:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=344d6d02690a650607e6372bce8fe40e647a51b5'/>
<id>344d6d02690a650607e6372bce8fe40e647a51b5</id>
<content type='text'>
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 &lt;ptikhomirov@virtuozzo.com&gt;
Tested-by: Pavel Tikhomirov &lt;ptikhomirov@virtuozzo.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;ptikhomirov@virtuozzo.com&gt;
Tested-by: Pavel Tikhomirov &lt;ptikhomirov@virtuozzo.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ses: Fix problems with simple enclosures</title>
<updated>2016-01-22T21:40:04+00:00</updated>
<author>
<name>James Bottomley</name>
<email>James.Bottomley@HansenPartnership.com</email>
</author>
<published>2015-12-08T17:00:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=25ef938516d26c3db9cb1f5b927ad7ee95be1022'/>
<id>25ef938516d26c3db9cb1f5b927ad7ee95be1022</id>
<content type='text'>
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 &lt;andrea.gelmini@gelma.net&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;andrea.gelmini@gelma.net&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi_sysfs: Fix queue_ramp_up_period return code</title>
<updated>2015-11-27T12:48:24+00:00</updated>
<author>
<name>Peter Oberparleiter</name>
<email>oberpar@linux.vnet.ibm.com</email>
</author>
<published>2015-10-27T09:49:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=74d26be3e560b7d8b2abca3dcb5430e9893d1767'/>
<id>74d26be3e560b7d8b2abca3dcb5430e9893d1767</id>
<content type='text'>
commit 863e02d0e173bb9d8cea6861be22820b25c076cc upstream.

Writing a number to /sys/bus/scsi/devices/&lt;sdev&gt;/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 &lt;oberpar@linux.vnet.ibm.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Matthew R. Ochs &lt;mrochs@linux.vnet.ibm.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 863e02d0e173bb9d8cea6861be22820b25c076cc upstream.

Writing a number to /sys/bus/scsi/devices/&lt;sdev&gt;/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 &lt;oberpar@linux.vnet.ibm.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Matthew R. Ochs &lt;mrochs@linux.vnet.ibm.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: restart list search after unlock in scsi_remove_target</title>
<updated>2015-11-27T12:48:23+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-10-19T14:35:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=67022ef102acafab56301d3e87ba7c4a3ee1b406'/>
<id>67022ef102acafab56301d3e87ba7c4a3ee1b406</id>
<content type='text'>
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 &lt;djbw@fb.com&gt;
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 &lt;JBottomley@Parallels.com&gt;
Date:   Tue Jan 21 07:01:41 2014 -0800

    [SCSI] dual scan thread bug fix

Thanks go to Dan Williams &lt;dan.j.williams@intel.com&gt; for tracking all this
prior history down.

Reported-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;djbw@fb.com&gt;
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 &lt;JBottomley@Parallels.com&gt;
Date:   Tue Jan 21 07:01:41 2014 -0800

    [SCSI] dual scan thread bug fix

Thanks go to Dan Williams &lt;dan.j.williams@intel.com&gt; for tracking all this
prior history down.

Reported-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>megaraid_sas : SMAP restriction--do not access user memory from IOCTL code</title>
<updated>2015-11-27T12:48:22+00:00</updated>
<author>
<name>sumit.saxena@avagotech.com</name>
<email>sumit.saxena@avagotech.com</email>
</author>
<published>2015-10-15T08:10:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f7e70badb0ee4fb9737bf9793e17eedd907b68f8'/>
<id>f7e70badb0ee4fb9737bf9793e17eedd907b68f8</id>
<content type='text'>
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 &lt;sumit.saxena@avagotech.com&gt;
Signed-off-by: Kashyap Desai &lt;kashyap.desai@avagotech.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sumit.saxena@avagotech.com&gt;
Signed-off-by: Kashyap Desai &lt;kashyap.desai@avagotech.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>megaraid_sas: Do not use PAGE_SIZE for max_sectors</title>
<updated>2015-11-27T12:48:22+00:00</updated>
<author>
<name>sumit.saxena@avagotech.com</name>
<email>sumit.saxena@avagotech.com</email>
</author>
<published>2015-10-15T08:10:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5e9c1dca8eb475a3f3e216cccf18f56dcdc7e6d8'/>
<id>5e9c1dca8eb475a3f3e216cccf18f56dcdc7e6d8</id>
<content type='text'>
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 &lt;sumit.saxena@avagotech.com&gt;
Signed-off-by: Kashyap Desai &lt;kashyap.desai@avagotech.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sumit.saxena@avagotech.com&gt;
Signed-off-by: Kashyap Desai &lt;kashyap.desai@avagotech.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mvsas: Fix NULL pointer dereference in mvs_slot_task_free</title>
<updated>2015-11-17T15:54:45+00:00</updated>
<author>
<name>Dāvis Mosāns</name>
<email>davispuh@gmail.com</email>
</author>
<published>2015-08-21T04:29:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cc1875ecbc3c9fb2774097e03870280c91c1e0e1'/>
<id>cc1875ecbc3c9fb2774097e03870280c91c1e0e1</id>
<content type='text'>
commit 2280521719e81919283b82902ac24058f87dfc1b upstream.

When pci_pool_alloc fails in mvs_task_prep then task-&gt;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 &lt;davispuh@gmail.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2280521719e81919283b82902ac24058f87dfc1b upstream.

When pci_pool_alloc fails in mvs_task_prep then task-&gt;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 &lt;davispuh@gmail.com&gt;
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>3w-9xxx: don't unmap bounce buffered commands</title>
<updated>2015-11-17T15:54:43+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-10-03T17:16:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=677ee63365fecb0d15df00fc6bd282b0ced7eaef'/>
<id>677ee63365fecb0d15df00fc6bd282b0ced7eaef</id>
<content type='text'>
commit 15e3d5a285ab9283136dba34bbf72886d9146706 upstream.

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 &lt;atoth@atoth.sote.hu&gt;
Tested-by: Tóth Attila &lt;atoth@atoth.sote.hu&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Adam Radford &lt;aradford@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 15e3d5a285ab9283136dba34bbf72886d9146706 upstream.

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 &lt;atoth@atoth.sote.hu&gt;
Tested-by: Tóth Attila &lt;atoth@atoth.sote.hu&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Adam Radford &lt;aradford@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libfc: Fix fc_fcp_cleanup_each_cmd()</title>
<updated>2015-10-13T02:46:03+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2015-06-05T21:20:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5813f566e1c8f7e0157388a9624f022d497c58a0'/>
<id>5813f566e1c8f7e0157388a9624f022d497c58a0</id>
<content type='text'>
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:  (&amp;(&amp;fsp-&gt;scsi_pkt_lock)-&gt;rlock){+.-...}, at: [&lt;ffffffffc0225cd5&gt;] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Preemption disabled at:[&lt;ffffffffc0225cd5&gt;] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Call Trace:
 [&lt;ffffffff816c612c&gt;] dump_stack+0x4f/0x7b
 [&lt;ffffffff810828bc&gt;] __schedule_bug+0x6c/0xd0
 [&lt;ffffffff816c87aa&gt;] __schedule+0x71a/0xa10
 [&lt;ffffffff816c8ad2&gt;] schedule+0x32/0x80
 [&lt;ffffffffc0217eac&gt;] fc_seq_set_resp+0xac/0x100 [libfc]
 [&lt;ffffffffc0218b11&gt;] fc_exch_done+0x41/0x60 [libfc]
 [&lt;ffffffffc0225cff&gt;] fc_fcp_cleanup_each_cmd.isra.21+0xcf/0x150 [libfc]
 [&lt;ffffffffc0225f43&gt;] fc_eh_device_reset+0x1c3/0x270 [libfc]
 [&lt;ffffffff814a2cc9&gt;] scsi_try_bus_device_reset+0x29/0x60
 [&lt;ffffffff814a3908&gt;] scsi_ioctl_reset+0x258/0x2d0
 [&lt;ffffffff814a2650&gt;] scsi_ioctl+0x150/0x440
 [&lt;ffffffff814b3a9d&gt;] sd_ioctl+0xad/0x120
 [&lt;ffffffff8132f266&gt;] blkdev_ioctl+0x1b6/0x810
 [&lt;ffffffff811da608&gt;] block_ioctl+0x38/0x40
 [&lt;ffffffff811b4e08&gt;] do_vfs_ioctl+0x2f8/0x530
 [&lt;ffffffff811b50c1&gt;] SyS_ioctl+0x81/0xa0
 [&lt;ffffffff816cf8b2&gt;] system_call_fastpath+0x16/0x7a

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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:  (&amp;(&amp;fsp-&gt;scsi_pkt_lock)-&gt;rlock){+.-...}, at: [&lt;ffffffffc0225cd5&gt;] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Preemption disabled at:[&lt;ffffffffc0225cd5&gt;] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc]
Call Trace:
 [&lt;ffffffff816c612c&gt;] dump_stack+0x4f/0x7b
 [&lt;ffffffff810828bc&gt;] __schedule_bug+0x6c/0xd0
 [&lt;ffffffff816c87aa&gt;] __schedule+0x71a/0xa10
 [&lt;ffffffff816c8ad2&gt;] schedule+0x32/0x80
 [&lt;ffffffffc0217eac&gt;] fc_seq_set_resp+0xac/0x100 [libfc]
 [&lt;ffffffffc0218b11&gt;] fc_exch_done+0x41/0x60 [libfc]
 [&lt;ffffffffc0225cff&gt;] fc_fcp_cleanup_each_cmd.isra.21+0xcf/0x150 [libfc]
 [&lt;ffffffffc0225f43&gt;] fc_eh_device_reset+0x1c3/0x270 [libfc]
 [&lt;ffffffff814a2cc9&gt;] scsi_try_bus_device_reset+0x29/0x60
 [&lt;ffffffff814a3908&gt;] scsi_ioctl_reset+0x258/0x2d0
 [&lt;ffffffff814a2650&gt;] scsi_ioctl+0x150/0x440
 [&lt;ffffffff814b3a9d&gt;] sd_ioctl+0xad/0x120
 [&lt;ffffffff8132f266&gt;] blkdev_ioctl+0x1b6/0x810
 [&lt;ffffffff811da608&gt;] block_ioctl+0x38/0x40
 [&lt;ffffffff811b4e08&gt;] do_vfs_ioctl+0x2f8/0x530
 [&lt;ffffffff811b50c1&gt;] SyS_ioctl+0x81/0xa0
 [&lt;ffffffff816cf8b2&gt;] system_call_fastpath+0x16/0x7a

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
