<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/scsi, branch v3.6.8</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>SCSI: isci: Allow SSP tasks into the task management path.</title>
<updated>2012-11-26T20:14:20+00:00</updated>
<author>
<name>Jeff Skirvin</name>
<email>jeffrey.d.skirvin@intel.com</email>
</author>
<published>2012-09-06T04:36:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0c46d72c25ddabd39d02ce5d63fc722f59671c1d'/>
<id>0c46d72c25ddabd39d02ce5d63fc722f59671c1d</id>
<content type='text'>
commit 54b46677757ff8d6c282305fc7710f466b63d6dc upstream.

This commit fixes a driver bug for SSP tasks that require task management
in the target after they complete in the SCU hardware.  The problem was
manifested in the function "isci_task_abort_task", which tests
to see if the sas_task.lldd_task is non-NULL before allowing task
management; this bug would always NULL lldd_task in the SCU I/O completion
path even if target management was required, which would prevent
task / target manangement from happening.

Note that in the case of SATA/STP targets, error recovery is provided by
the libata error handler which is why SATA/STP device recovery worked
correctly even though SSP handling did not.

Signed-off-by: Jeff Skirvin &lt;jeffrey.d.skirvin@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Cc: "Dorau, Lukasz" &lt;lukasz.dorau@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 54b46677757ff8d6c282305fc7710f466b63d6dc upstream.

This commit fixes a driver bug for SSP tasks that require task management
in the target after they complete in the SCU hardware.  The problem was
manifested in the function "isci_task_abort_task", which tests
to see if the sas_task.lldd_task is non-NULL before allowing task
management; this bug would always NULL lldd_task in the SCU I/O completion
path even if target management was required, which would prevent
task / target manangement from happening.

Note that in the case of SATA/STP targets, error recovery is provided by
the libata error handler which is why SATA/STP device recovery worked
correctly even though SSP handling did not.

Signed-off-by: Jeff Skirvin &lt;jeffrey.d.skirvin@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Cc: "Dorau, Lukasz" &lt;lukasz.dorau@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>qla2xxx: Update target lookup session tables when a target session changes</title>
<updated>2012-11-05T08:56:51+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-10-11T20:41:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aa927fcb2d23c7f0b1e350335eb822f5179c49a9'/>
<id>aa927fcb2d23c7f0b1e350335eb822f5179c49a9</id>
<content type='text'>
commit c8292d1da53fa60c7516ab03a9d83f7ea266d335 upstream.

It is possible for the target code to change the loop_id or s_id of a
target session in reaction to an FC fabric change.  However, the
session structures are stored in tables that are indexed by these two
keys, and if we just change the session structure but leave the
pointers to it in the old places in the table, havoc can ensue.  For
example, a new session might come along that should go in the old slot
in the table and overwrite the old session pointer.

To handle this, add a new tgt_ops-&gt;update_sess() method that also
updates the "by loop_id" and "by s_id" lookup tables when a session
changes, so that the keys where a session pointer is stored in these
tables always matches the keys in the session structure itself.

(nab: Drop unnecessary double inversion with FCF_CONF_COMP_SUPPORTED
      usage)

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Cc: Arun Easi &lt;arun.easi@qlogic.com&gt;
Cc: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c8292d1da53fa60c7516ab03a9d83f7ea266d335 upstream.

It is possible for the target code to change the loop_id or s_id of a
target session in reaction to an FC fabric change.  However, the
session structures are stored in tables that are indexed by these two
keys, and if we just change the session structure but leave the
pointers to it in the old places in the table, havoc can ensue.  For
example, a new session might come along that should go in the old slot
in the table and overwrite the old session pointer.

To handle this, add a new tgt_ops-&gt;update_sess() method that also
updates the "by loop_id" and "by s_id" lookup tables when a session
changes, so that the keys where a session pointer is stored in these
tables always matches the keys in the session structure itself.

(nab: Drop unnecessary double inversion with FCF_CONF_COMP_SUPPORTED
      usage)

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Cc: Arun Easi &lt;arun.easi@qlogic.com&gt;
Cc: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>qla2xxx: Fix endianness of task management response code</title>
<updated>2012-10-21T16:32:40+00:00</updated>
<author>
<name>Roland Dreier</name>
<email>roland@purestorage.com</email>
</author>
<published>2012-09-18T22:10:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1a5392619baf037a0aab6689ece7f4b9368d81be'/>
<id>1a5392619baf037a0aab6689ece7f4b9368d81be</id>
<content type='text'>
commit e4b11b89f9039ca97b2ed1b6efeb6749fbdeb252 upstream.

The qla2xxx firmware actually expects the task management response
code in a CTIO IOCB with SCSI status mode 1 to be in little-endian
byte order, ie the response code should be the first byte in the
sense_data[] array.  The old code erroneously byte-swapped the
response code, which puts it in the wrong place on the wire and leads
to initiators thinking every task management request succeeds (since
they see 0 in the byte where they look for the response code).

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Cc: Arun Easi &lt;arun.easi@qlogic.com&gt;
Acked-by: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e4b11b89f9039ca97b2ed1b6efeb6749fbdeb252 upstream.

The qla2xxx firmware actually expects the task management response
code in a CTIO IOCB with SCSI status mode 1 to be in little-endian
byte order, ie the response code should be the first byte in the
sense_data[] array.  The old code erroneously byte-swapped the
response code, which puts it in the wrong place on the wire and leads
to initiators thinking every task management request succeeds (since
they see 0 in the byte where they look for the response code).

Signed-off-by: Roland Dreier &lt;roland@purestorage.com&gt;
Cc: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Cc: Arun Easi &lt;arun.easi@qlogic.com&gt;
Acked-by: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: virtio-scsi: initialize scatterlist structure</title>
<updated>2012-10-21T16:32:39+00:00</updated>
<author>
<name>Richard W.M. Jones</name>
<email>rjones@redhat.com</email>
</author>
<published>2012-10-02T15:25:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6eac60584d2030cc4d47ef3fc2738012416d8c4f'/>
<id>6eac60584d2030cc4d47ef3fc2738012416d8c4f</id>
<content type='text'>
commit 2e9c9dfde00a6466441e93033cf2c37f720bdacf upstream.

The sg struct is used without being initialized, which breaks
when CONFIG_DEBUG_SG is enabled.

Signed-off-by: Richard W.M. Jones &lt;rjones@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2e9c9dfde00a6466441e93033cf2c37f720bdacf upstream.

The sg struct is used without being initialized, which breaks
when CONFIG_DEBUG_SG is enabled.

Signed-off-by: Richard W.M. Jones &lt;rjones@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: scsi_debug: Fix off-by-one bug when unmapping region</title>
<updated>2012-10-21T16:32:39+00:00</updated>
<author>
<name>Lukas Czerner</name>
<email>lczerner@redhat.com</email>
</author>
<published>2012-08-16T14:38:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=22273f50017471428d85e3e6c6d04020fcaec97d'/>
<id>22273f50017471428d85e3e6c6d04020fcaec97d</id>
<content type='text'>
commit bc977749e967daa56de1922cf4cb38525631c51c upstream.

Currently it is possible to unmap one more block than user requested to
due to the off-by-one error in unmap_region(). This is probably due to
the fact that the end variable despite its name actually points to the
last block to unmap + 1. However in the condition it is handled as the
last block of the region to unmap.

The bug was not previously spotted probably due to the fact that the
region was not zeroed, which has changed with commit
be1dd78de5686c062bb3103f9e86d444a10ed783. With that commit we were able
to corrupt the ext4 file system on 256M scsi_debug device with LBPRZ
enabled using fstrim.

Since the 'end' semantic is the same in several functions there this
commit just fixes the condition to use the 'end' variable correctly in
that context.

Reported-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Lukas Czerner &lt;lczerner@redhat.com&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Acked-by: Douglas Gilbert &lt;dgilbert@interlog.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bc977749e967daa56de1922cf4cb38525631c51c upstream.

Currently it is possible to unmap one more block than user requested to
due to the off-by-one error in unmap_region(). This is probably due to
the fact that the end variable despite its name actually points to the
last block to unmap + 1. However in the condition it is handled as the
last block of the region to unmap.

The bug was not previously spotted probably due to the fact that the
region was not zeroed, which has changed with commit
be1dd78de5686c062bb3103f9e86d444a10ed783. With that commit we were able
to corrupt the ext4 file system on 256M scsi_debug device with LBPRZ
enabled using fstrim.

Since the 'end' semantic is the same in several functions there this
commit just fixes the condition to use the 'end' variable correctly in
that context.

Reported-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Lukas Czerner &lt;lczerner@redhat.com&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Acked-by: Douglas Gilbert &lt;dgilbert@interlog.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: storvsc: Account for in-transit packets in the RESET path</title>
<updated>2012-10-21T16:32:39+00:00</updated>
<author>
<name>K. Y. Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2012-10-02T18:03:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=54acbe4085b9c629e0164c90211d55e54e0ec6c0'/>
<id>54acbe4085b9c629e0164c90211d55e54e0ec6c0</id>
<content type='text'>
commit 5c1b10ab7f93d24f29b5630286e323d1c5802d5c upstream.

Properly account for I/O in transit before returning from the RESET call.
In the absense of this patch, we could have a situation where the host may
respond to a command that was issued prior to the issuance of the RESET
command at some arbitrary time after responding to the RESET command.
Currently, the host does not do anything with the RESET command.

Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5c1b10ab7f93d24f29b5630286e323d1c5802d5c upstream.

Properly account for I/O in transit before returning from the RESET call.
In the absense of this patch, we could have a situation where the host may
respond to a command that was issued prior to the issuance of the RESET
command at some arbitrary time after responding to the RESET command.
Currently, the host does not do anything with the RESET command.

Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/scsi/atp870u.c: fix bad use of udelay</title>
<updated>2012-10-12T20:50:19+00:00</updated>
<author>
<name>Martin Michlmayr</name>
<email>tbm@cyrius.com</email>
</author>
<published>2012-10-05T00:11:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4b45def3ed7625fa553eb8ae42624dd7dd3239e7'/>
<id>4b45def3ed7625fa553eb8ae42624dd7dd3239e7</id>
<content type='text'>
commit 0f6d93aa9d96cc9022b51bd10d462b03296be146 upstream.

The ACARD driver calls udelay() with a value &gt; 2000, which leads to to
the following compilation error on ARM:

  ERROR: "__bad_udelay" [drivers/scsi/atp870u.ko] undefined!
  make[1]: *** [__modpost] Error 1

This is because udelay is defined on ARM, roughly speaking, as

	#define udelay(n) ((n) &gt; 2000 ? __bad_udelay() : \
		__const_udelay((n) * ((2199023U*HZ)&gt;&gt;11)))

The argument to __const_udelay is the number of jiffies to wait divided
by 4, but this does not work unless the multiplication does not
overflow, and that is what the build error is designed to prevent.  The
intended behavior can be achieved by using mdelay to call udelay
multiple times in a loop.

[jrnieder@gmail.com: adding context]
Signed-off-by: Martin Michlmayr &lt;tbm@cyrius.com&gt;
Signed-off-by: Jonathan Nieder &lt;jrnieder@gmail.com&gt;
Cc: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0f6d93aa9d96cc9022b51bd10d462b03296be146 upstream.

The ACARD driver calls udelay() with a value &gt; 2000, which leads to to
the following compilation error on ARM:

  ERROR: "__bad_udelay" [drivers/scsi/atp870u.ko] undefined!
  make[1]: *** [__modpost] Error 1

This is because udelay is defined on ARM, roughly speaking, as

	#define udelay(n) ((n) &gt; 2000 ? __bad_udelay() : \
		__const_udelay((n) * ((2199023U*HZ)&gt;&gt;11)))

The argument to __const_udelay is the number of jiffies to wait divided
by 4, but this does not work unless the multiplication does not
overflow, and that is what the build error is designed to prevent.  The
intended behavior can be achieved by using mdelay to call udelay
multiple times in a loop.

[jrnieder@gmail.com: adding context]
Signed-off-by: Martin Michlmayr &lt;tbm@cyrius.com&gt;
Signed-off-by: Jonathan Nieder &lt;jrnieder@gmail.com&gt;
Cc: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: scsi_dh_alua: Enable STPG for unavailable ports</title>
<updated>2012-10-07T15:39:36+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2012-08-24T09:08:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=49a1ecd51adc4fb6cc229840c568ad19b051190d'/>
<id>49a1ecd51adc4fb6cc229840c568ad19b051190d</id>
<content type='text'>
commit e47f8976d8e573928824a06748f7bc82c58d747f upstream.

A quote from SPC-4: "While in the unavailable primary target port
asymmetric access state, the device server shall support those of
the following commands that it supports while in the active/optimized
state: [ ... ] d) SET TARGET PORT GROUPS; [ ... ]". Hence enable
sending STPG to a target port group that is in the unavailable state.

Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Reviewed-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Acked-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e47f8976d8e573928824a06748f7bc82c58d747f upstream.

A quote from SPC-4: "While in the unavailable primary target port
asymmetric access state, the device server shall support those of
the following commands that it supports while in the active/optimized
state: [ ... ] d) SET TARGET PORT GROUPS; [ ... ]". Hence enable
sending STPG to a target port group that is in the unavailable state.

Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Reviewed-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Acked-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: scsi_remove_target: fix softlockup regression on hot remove</title>
<updated>2012-10-07T15:39:36+00:00</updated>
<author>
<name>Dan Williams</name>
<email>djbw@fb.com</email>
</author>
<published>2012-08-29T05:12:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8b8706101460ed34e6f05aa8f577b9829221130d'/>
<id>8b8706101460ed34e6f05aa8f577b9829221130d</id>
<content type='text'>
commit bc3f02a795d3b4faa99d37390174be2a75d091bd upstream.

John reports:
 BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
 [..]
 Call Trace:
  [&lt;ffffffff8141782a&gt;] scsi_remove_target+0xda/0x1f0
  [&lt;ffffffff81421de5&gt;] sas_rphy_remove+0x55/0x60
  [&lt;ffffffff81421e01&gt;] sas_rphy_delete+0x11/0x20
  [&lt;ffffffff81421e35&gt;] sas_port_delete+0x25/0x160
  [&lt;ffffffff814549a3&gt;] mptsas_del_end_device+0x183/0x270

...introduced by commit 3b661a9 "[SCSI] fix hot unplug vs async scan race".

Don't restart lookup of more stargets in the multi-target case, just
arrange to traverse the list once, on the assumption that new targets
are always added at the end.  There is no guarantee that the target will
change state in scsi_target_reap() so we can end up spinning if we
restart.

Acked-by: Jack Wang &lt;jack_wang@usish.com&gt;
LKML-Reference: &lt;CAEhu1-6wq1YsNiscGMwP4ud0Q+MrViRzv=kcWCQSBNc8c68N5Q@mail.gmail.com&gt;
Reported-by: John Drescher &lt;drescherjm@gmail.com&gt;
Tested-by: John Drescher &lt;drescherjm@gmail.com&gt;
Signed-off-by: Dan Williams &lt;djbw@fb.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bc3f02a795d3b4faa99d37390174be2a75d091bd upstream.

John reports:
 BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
 [..]
 Call Trace:
  [&lt;ffffffff8141782a&gt;] scsi_remove_target+0xda/0x1f0
  [&lt;ffffffff81421de5&gt;] sas_rphy_remove+0x55/0x60
  [&lt;ffffffff81421e01&gt;] sas_rphy_delete+0x11/0x20
  [&lt;ffffffff81421e35&gt;] sas_port_delete+0x25/0x160
  [&lt;ffffffff814549a3&gt;] mptsas_del_end_device+0x183/0x270

...introduced by commit 3b661a9 "[SCSI] fix hot unplug vs async scan race".

Don't restart lookup of more stargets in the multi-target case, just
arrange to traverse the list once, on the assumption that new targets
are always added at the end.  There is no guarantee that the target will
change state in scsi_target_reap() so we can end up spinning if we
restart.

Acked-by: Jack Wang &lt;jack_wang@usish.com&gt;
LKML-Reference: &lt;CAEhu1-6wq1YsNiscGMwP4ud0Q+MrViRzv=kcWCQSBNc8c68N5Q@mail.gmail.com&gt;
Reported-by: John Drescher &lt;drescherjm@gmail.com&gt;
Tested-by: John Drescher &lt;drescherjm@gmail.com&gt;
Signed-off-by: Dan Williams &lt;djbw@fb.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>isci: fix isci_pci_probe() generates warning on efi failure path</title>
<updated>2012-10-07T15:39:36+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2012-06-22T18:31:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0651bd3e20bb320f32ede9773e9d0ec0e569ab96'/>
<id>0651bd3e20bb320f32ede9773e9d0ec0e569ab96</id>
<content type='text'>
commit 6d70a74ffd616073a68ae0974d98819bfa8e6da6 upstream.

The oem parameter image embedded in the efi variable is at an offset
from the start of the variable.  However, in the failure path we try to
free the 'orom' pointer which is only valid when the paramaters are
being read from the legacy option-rom space.

Since failure to load the oem parameters is unlikely and we keep the
memory around in the success case just defer all de-allocation to devm.

Reported-by: Don Morris &lt;don.morris@hp.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6d70a74ffd616073a68ae0974d98819bfa8e6da6 upstream.

The oem parameter image embedded in the efi variable is at an offset
from the start of the variable.  However, in the failure path we try to
free the 'orom' pointer which is only valid when the paramaters are
being read from the legacy option-rom space.

Since failure to load the oem parameters is unlikely and we keep the
memory around in the success case just defer all de-allocation to devm.

Reported-by: Don Morris &lt;don.morris@hp.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
