<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/scsi, branch v3.16.48</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>scsi: scsi_error: count medium access timeout only once per EH run</title>
<updated>2017-08-26T01:14:29+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2017-04-06T13:36:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1513208e76966c456deb438a7dadd19adac1760a'/>
<id>1513208e76966c456deb438a7dadd19adac1760a</id>
<content type='text'>
commit 7a38dc0bfb4cc39ed57e120e2224673f3d4d200f upstream.

The current medium access timeout counter will be increased for
each command, so if there are enough failed commands we'll hit
the medium access timeout for even a single device failure and
the following kernel message is displayed:

sd H:C:T:L: [sdXY] Medium access timeout failure. Offlining disk!

Fix this by making the timeout per EH run, ie the counter will
only be increased once per device and EH run.

Fixes: 18a4d0a ("[SCSI] Handle disk devices which can not process medium access commands")
Cc: Ewan Milne &lt;emilne@redhat.com&gt;
Cc: Lawrence Obermann &lt;loberman@redhat.com&gt;
Cc: Benjamin Block &lt;bblock@linux.vnet.ibm.com&gt;
Cc: Steffen Maier &lt;maier@linux.vnet.ibm.com&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
[bwh: Backported to 3.16:
 - Open-code blk_rq_is_passthrough()
 - Adjust context]
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 7a38dc0bfb4cc39ed57e120e2224673f3d4d200f upstream.

The current medium access timeout counter will be increased for
each command, so if there are enough failed commands we'll hit
the medium access timeout for even a single device failure and
the following kernel message is displayed:

sd H:C:T:L: [sdXY] Medium access timeout failure. Offlining disk!

Fix this by making the timeout per EH run, ie the counter will
only be increased once per device and EH run.

Fixes: 18a4d0a ("[SCSI] Handle disk devices which can not process medium access commands")
Cc: Ewan Milne &lt;emilne@redhat.com&gt;
Cc: Lawrence Obermann &lt;loberman@redhat.com&gt;
Cc: Benjamin Block &lt;bblock@linux.vnet.ibm.com&gt;
Cc: Steffen Maier &lt;maier@linux.vnet.ibm.com&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
[bwh: Backported to 3.16:
 - Open-code blk_rq_is_passthrough()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: libiscsi: add lock around task lists to fix list corruption regression</title>
<updated>2017-07-18T17:40:05+00:00</updated>
<author>
<name>Chris Leech</name>
<email>cleech@redhat.com</email>
</author>
<published>2017-02-28T00:58:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e57d94724b2866c161fe802db1786a39ea3c1b07'/>
<id>e57d94724b2866c161fe802db1786a39ea3c1b07</id>
<content type='text'>
commit 6f8830f5bbab16e54f261de187f3df4644a5b977 upstream.

There's a rather long standing regression from the commit "libiscsi:
Reduce locking contention in fast path"

Depending on iSCSI target behavior, it's possible to hit the case in
iscsi_complete_task where the task is still on a pending list
(!list_empty(&amp;task-&gt;running)).  When that happens the task is removed
from the list while holding the session back_lock, but other task list
modification occur under the frwd_lock.  That leads to linked list
corruption and eventually a panicked system.

Rather than back out the session lock split entirely, in order to try
and keep some of the performance gains this patch adds another lock to
maintain the task lists integrity.

Major enterprise supported kernels have been backing out the lock split
for while now, thanks to the efforts at IBM where a lab setup has the
most reliable reproducer I've seen on this issue.  This patch has been
tested there successfully.

Signed-off-by: Chris Leech &lt;cleech@redhat.com&gt;
Fixes: 659743b02c41 ("[SCSI] libiscsi: Reduce locking contention in fast path")
Reported-by: Prashantha Subbarao &lt;psubbara@us.ibm.com&gt;
Reviewed-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.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 6f8830f5bbab16e54f261de187f3df4644a5b977 upstream.

There's a rather long standing regression from the commit "libiscsi:
Reduce locking contention in fast path"

Depending on iSCSI target behavior, it's possible to hit the case in
iscsi_complete_task where the task is still on a pending list
(!list_empty(&amp;task-&gt;running)).  When that happens the task is removed
from the list while holding the session back_lock, but other task list
modification occur under the frwd_lock.  That leads to linked list
corruption and eventually a panicked system.

Rather than back out the session lock split entirely, in order to try
and keep some of the performance gains this patch adds another lock to
maintain the task lists integrity.

Major enterprise supported kernels have been backing out the lock split
for while now, thanks to the efforts at IBM where a lab setup has the
most reliable reproducer I've seen on this issue.  This patch has been
tested there successfully.

Signed-off-by: Chris Leech &lt;cleech@redhat.com&gt;
Fixes: 659743b02c41 ("[SCSI] libiscsi: Reduce locking contention in fast path")
Reported-by: Prashantha Subbarao &lt;psubbara@us.ibm.com&gt;
Reviewed-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.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: Add intermediate STARGET_REMOVE state to scsi_target_state</title>
<updated>2016-08-22T21:37:50+00:00</updated>
<author>
<name>Johannes Thumshirn</name>
<email>jthumshirn@suse.de</email>
</author>
<published>2016-04-05T09:50:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3473e5db18c74469fd86237bbc2437f9beb6458e'/>
<id>3473e5db18c74469fd86237bbc2437f9beb6458e</id>
<content type='text'>
commit f05795d3d771f30a7bdc3a138bf714b06d42aa95 upstream.

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
state is only valid in the path from scsi_remove_target() to
scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and
40998193560d ("scsi: restart list search after unlock in
scsi_remove_target") in a more comprehensive way.

[mkp: Included James' fix for scsi_target_destroy()]

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
Reported-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Tested-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: James Bottomley &lt;jejb@linux.vnet.ibm.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 f05795d3d771f30a7bdc3a138bf714b06d42aa95 upstream.

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
state is only valid in the path from scsi_remove_target() to
scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and
40998193560d ("scsi: restart list search after unlock in
scsi_remove_target") in a more comprehensive way.

[mkp: Included James' fix for scsi_target_destroy()]

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
Reported-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Tested-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: James Bottomley &lt;jejb@linux.vnet.ibm.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: add 1024 max sectors black list flag</title>
<updated>2015-05-12T08:36:36+00:00</updated>
<author>
<name>Mike Christie</name>
<email>michaelc@cs.wisc.edu</email>
</author>
<published>2015-04-21T03:42:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b4fd6000723d159f2cd1d2d3279b32555e59fb58'/>
<id>b4fd6000723d159f2cd1d2d3279b32555e59fb58</id>
<content type='text'>
commit 35e9a9f93994d7f7d12afa41169c7ba05513721b upstream.

This works around a issue with qnap iscsi targets not handling large IOs
very well.

The target returns:

VPD INQUIRY: Block limits page (SBC)
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 4294967295 blocks
  Optimal transfer length: 4294967295 blocks
  Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
  Maximum unmap LBA count: 8388607
  Maximum unmap block descriptor count: 1
  Optimal unmap granularity: 16383
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0xffffffff blocks
  Maximum atomic transfer length: 0
  Atomic alignment: 0
  Atomic transfer length granularity: 0

and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
have seen in traces where it will sometimes work, but other times it
looks like it fails and it looks like it returns failures if we send
multiple large IOs sometimes. Also it looks like it can return 2 different
errors. It will sometimes send iscsi reject errors indicating out of
resources or it will send invalid cdb illegal requests check conditions.
And then when it sends iscsi rejects it does not seem to handle retries
when there are command sequence holes, so I could not just add code to
try and gracefully handle that error code.

The problem is that we do not have a good contact for the company,
so we are not able to determine under what conditions it returns
which error and why it sometimes works.

So, this patch just adds a new black list flag to set targets like this to
the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
caused this regression, so I also ccing stable.

Reported-by: Christian Hesse &lt;list@eworm.de&gt;
Signed-off-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 35e9a9f93994d7f7d12afa41169c7ba05513721b upstream.

This works around a issue with qnap iscsi targets not handling large IOs
very well.

The target returns:

VPD INQUIRY: Block limits page (SBC)
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 4294967295 blocks
  Optimal transfer length: 4294967295 blocks
  Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
  Maximum unmap LBA count: 8388607
  Maximum unmap block descriptor count: 1
  Optimal unmap granularity: 16383
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0xffffffff blocks
  Maximum atomic transfer length: 0
  Atomic alignment: 0
  Atomic transfer length granularity: 0

and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
have seen in traces where it will sometimes work, but other times it
looks like it fails and it looks like it returns failures if we send
multiple large IOs sometimes. Also it looks like it can return 2 different
errors. It will sometimes send iscsi reject errors indicating out of
resources or it will send invalid cdb illegal requests check conditions.
And then when it sends iscsi rejects it does not seem to handle retries
when there are command sequence holes, so I could not just add code to
try and gracefully handle that error code.

The problem is that we do not have a good contact for the company,
so we are not able to determine under what conditions it returns
which error and why it sometimes works.

So, this patch just adds a new black list flag to set targets like this to
the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
caused this regression, so I also ccing stable.

Reported-by: Christian Hesse &lt;list@eworm.de&gt;
Signed-off-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: do not issue SCSI RSOC command to Promise Vtrak E610f</title>
<updated>2014-09-17T16:22:00+00:00</updated>
<author>
<name>Janusz Dziemidowicz</name>
<email>rraptorr@nails.eu.org</email>
</author>
<published>2014-07-24T13:48:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1633efbdd3ee5dccb0eba190379a0ebaf5e32cf3'/>
<id>1633efbdd3ee5dccb0eba190379a0ebaf5e32cf3</id>
<content type='text'>
commit 0213436a2cc5e4a5ca2fabfaa4d3877097f3b13f upstream.

Some devices don't like REPORT SUPPORTED OPERATION CODES and will
simply timeout causing sd_mod init to take a very very long time.
Introduce BLIST_NO_RSOC scsi scan flag, that stops RSOC from being
issued. Add it to Promise Vtrak E610f entry in scsi scan
blacklist. Fixes bug #79901 reported at
https://bugzilla.kernel.org/show_bug.cgi?id=79901

Fixes: 98dcc2946adb ("SCSI: sd: Update WRITE SAME heuristics")

Signed-off-by: Janusz Dziemidowicz &lt;rraptorr@nails.eu.org&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&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 0213436a2cc5e4a5ca2fabfaa4d3877097f3b13f upstream.

Some devices don't like REPORT SUPPORTED OPERATION CODES and will
simply timeout causing sd_mod init to take a very very long time.
Introduce BLIST_NO_RSOC scsi scan flag, that stops RSOC from being
issued. Add it to Promise Vtrak E610f entry in scsi scan
blacklist. Fixes bug #79901 reported at
https://bugzilla.kernel.org/show_bug.cgi?id=79901

Fixes: 98dcc2946adb ("SCSI: sd: Update WRITE SAME heuristics")

Signed-off-by: Janusz Dziemidowicz &lt;rraptorr@nails.eu.org&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: add a blacklist flag which enables VPD page inquiries</title>
<updated>2014-09-17T16:22:00+00:00</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2014-07-15T16:49:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fe06acc43ff994f1d8461668c40cbe4b1946c376'/>
<id>fe06acc43ff994f1d8461668c40cbe4b1946c376</id>
<content type='text'>
commit c1d40a527e885a40bb9ea6c46a1b1145d42b66a0 upstream.

Despite supporting modern SCSI features some storage devices continue to
claim conformance to an older version of the SPC spec. This is done for
compatibility with legacy operating systems.

Linux by default will not attempt to read VPD pages on devices that
claim SPC-2 or older. Introduce a blacklist flag that can be used to
trigger VPD page inquiries on devices that are known to support them.

Reported-by: KY Srinivasan &lt;kys@microsoft.com&gt;
Tested-by: KY Srinivasan &lt;kys@microsoft.com&gt;
Reviewed-by: KY Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&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 c1d40a527e885a40bb9ea6c46a1b1145d42b66a0 upstream.

Despite supporting modern SCSI features some storage devices continue to
claim conformance to an older version of the SPC spec. This is done for
compatibility with legacy operating systems.

Linux by default will not attempt to read VPD pages on devices that
claim SPC-2 or older. Introduce a blacklist flag that can be used to
trigger VPD page inquiries on devices that are known to support them.

Reported-by: KY Srinivasan &lt;kys@microsoft.com&gt;
Tested-by: KY Srinivasan &lt;kys@microsoft.com&gt;
Reviewed-by: KY Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi_scan: Restrict sequential scan to 256 LUNs</title>
<updated>2014-09-17T16:21:59+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2014-06-03T08:58:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=689fb61cd60d2c5abf92aa65a2a3a8cc1500980a'/>
<id>689fb61cd60d2c5abf92aa65a2a3a8cc1500980a</id>
<content type='text'>
commit 22ffeb48b7584d6cd50f2a595ed6065d86a87459 upstream.

Sequential scan for more than 256 LUNs is very fragile as
LUNs might not be numbered sequentially after that point.

SAM revisions later than SCSI-3 impose a structure on
LUNs larger than 256, making LUN numbers between 256
and 16384 illegal.
SCSI-3, however allows for plain 64-bit numbers with
no internal structure.

So restrict sequential LUN scan to 256 LUNs and add a
new blacklist flag 'BLIST_SCSI3LUN' to scan up to
max_lun devices.

Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Ewan Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&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 22ffeb48b7584d6cd50f2a595ed6065d86a87459 upstream.

Sequential scan for more than 256 LUNs is very fragile as
LUNs might not be numbered sequentially after that point.

SAM revisions later than SCSI-3 impose a structure on
LUNs larger than 256, making LUN numbers between 256
and 16384 illegal.
SCSI-3, however allows for plain 64-bit numbers with
no internal structure.

So restrict sequential LUN scan to 256 LUNs and add a
new blacklist flag 'BLIST_SCSI3LUN' to scan up to
max_lun devices.

Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Ewan Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2014-07-06T19:08:30+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-07-06T19:08:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8addf0c713061aad2fc256181be3ceac221ac215'/>
<id>8addf0c713061aad2fc256181be3ceac221ac215</id>
<content type='text'>
Pull SCSI fixes from James Bottomley:
 "This is a set of 13 fixes, a MAINTAINERS update and a sparse update.
  The fixes are mostly correct value initialisations, avoiding NULL
  derefs and some uninitialised pointer avoidance.

  All the patches have been incubated in -next for a few days.  The
  final patch (use the scsi data buffer length to extract transfer size)
  has been rebased to add a cc to stable, but only the commit message
  has changed"

* tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] use the scsi data buffer length to extract transfer size
  virtio-scsi: fix various bad behavior on aborted requests
  virtio-scsi: avoid cancelling uninitialized work items
  ibmvscsi: Add memory barriers for send / receive
  ibmvscsi: Abort init sequence during error recovery
  qla2xxx: Fix sparse warning in qla_target.c.
  bnx2fc: Improve stats update mechanism
  bnx2fc: do not scan uninitialized lists in case of error.
  fc: ensure scan_work isn't active when freeing fc_rport
  pm8001: Fix potential null pointer dereference and memory leak.
  MAINTAINERS: Update LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) maintainers Email IDs
  be2iscsi: remove potential junk pointer free
  be2iscsi: add an missing goto in error path
  scsi_error: set DID_TIME_OUT correctly
  scsi_error: fix invalid setting of host byte
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull SCSI fixes from James Bottomley:
 "This is a set of 13 fixes, a MAINTAINERS update and a sparse update.
  The fixes are mostly correct value initialisations, avoiding NULL
  derefs and some uninitialised pointer avoidance.

  All the patches have been incubated in -next for a few days.  The
  final patch (use the scsi data buffer length to extract transfer size)
  has been rebased to add a cc to stable, but only the commit message
  has changed"

* tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] use the scsi data buffer length to extract transfer size
  virtio-scsi: fix various bad behavior on aborted requests
  virtio-scsi: avoid cancelling uninitialized work items
  ibmvscsi: Add memory barriers for send / receive
  ibmvscsi: Abort init sequence during error recovery
  qla2xxx: Fix sparse warning in qla_target.c.
  bnx2fc: Improve stats update mechanism
  bnx2fc: do not scan uninitialized lists in case of error.
  fc: ensure scan_work isn't active when freeing fc_rport
  pm8001: Fix potential null pointer dereference and memory leak.
  MAINTAINERS: Update LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) maintainers Email IDs
  be2iscsi: remove potential junk pointer free
  be2iscsi: add an missing goto in error path
  scsi_error: set DID_TIME_OUT correctly
  scsi_error: fix invalid setting of host byte
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] use the scsi data buffer length to extract transfer size</title>
<updated>2014-07-03T17:50:31+00:00</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2014-06-24T14:59:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5616b0a46ed82eb9a093f752fc4d7bd3cc688583'/>
<id>5616b0a46ed82eb9a093f752fc4d7bd3cc688583</id>
<content type='text'>
Commit 8846bab180fa introduced a helper that can be used to query the
wire transfer size for a SCSI command taking protection information into
account.

However, some commands do not have a 1:1 mapping between the block range
they work on and the payload size (discard, write same). After the
scatterlist has been set up these requests use __data_len to store the
number of bytes to report completion on. This means that callers of
scsi_transfer_length() would get the wrong byte count for these types of
requests.

To overcome this we make scsi_transfer_length() use the scatterlist
length in the scsi_data_buffer as basis for the wire transfer
calculation instead of __data_len.

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Debugged-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Fixes: d77e65350f2d82dfa0557707d505711f5a43c8fd
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 8846bab180fa introduced a helper that can be used to query the
wire transfer size for a SCSI command taking protection information into
account.

However, some commands do not have a 1:1 mapping between the block range
they work on and the payload size (discard, write same). After the
scatterlist has been set up these requests use __data_len to store the
number of bytes to report completion on. This means that callers of
scsi_transfer_length() would get the wrong byte count for these types of
requests.

To overcome this we make scsi_transfer_length() use the scatterlist
length in the scsi_data_buffer as basis for the wire transfer
calculation instead of __data_len.

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Debugged-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Fixes: d77e65350f2d82dfa0557707d505711f5a43c8fd
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb-storage/SCSI: Add broken_fua blacklist flag</title>
<updated>2014-07-01T05:47:18+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2014-06-30T15:04:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b14bf2d0c0358140041d1c1805a674376964d0e0'/>
<id>b14bf2d0c0358140041d1c1805a674376964d0e0</id>
<content type='text'>
Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs.  This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Michael Büsch &lt;m@bues.ch&gt;
Tested-by: Michael Büsch &lt;m@bues.ch&gt;
Acked-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
CC: Matthew Dharm &lt;mdharm-usb@one-eyed-alien.net&gt;
CC: &lt;stable@vger.kernel.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>
Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs.  This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Michael Büsch &lt;m@bues.ch&gt;
Tested-by: Michael Büsch &lt;m@bues.ch&gt;
Acked-by: James Bottomley &lt;James.Bottomley@HansenPartnership.com&gt;
CC: Matthew Dharm &lt;mdharm-usb@one-eyed-alien.net&gt;
CC: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
