<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/scsi, branch linux-4.0.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-4.0.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-4.0.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2015-07-21T17:10:14+00:00</updated>
<entry>
<title>scsi_transport_srp: Fix a race condition</title>
<updated>2015-07-21T17:10:14+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2015-05-18T11:22:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f430f36d61afe82938c3d632bfb6bab21e6403a7'/>
<id>urn:sha1:f430f36d61afe82938c3d632bfb6bab21e6403a7</id>
<content type='text'>
commit 535fb906225fb7436cb658144d0c0cea14a26f3e upstream.

Avoid that srp_terminate_io() can get invoked while srp_queuecommand()
is in progress. This patch avoids that an I/O timeout can trigger the
following kernel warning:

WARNING: at drivers/infiniband/ulp/srp/ib_srp.c:1447 srp_terminate_io+0xef/0x100 [ib_srp]()
Call Trace:
 [&lt;ffffffff814c65a2&gt;] dump_stack+0x4e/0x68
 [&lt;ffffffff81051f71&gt;] warn_slowpath_common+0x81/0xa0
 [&lt;ffffffff8105204a&gt;] warn_slowpath_null+0x1a/0x20
 [&lt;ffffffffa075f51f&gt;] srp_terminate_io+0xef/0x100 [ib_srp]
 [&lt;ffffffffa07495da&gt;] __rport_fail_io_fast+0xba/0xc0 [scsi_transport_srp]
 [&lt;ffffffffa0749a90&gt;] rport_fast_io_fail_timedout+0xe0/0xf0 [scsi_transport_srp]
 [&lt;ffffffff8106e09b&gt;] process_one_work+0x1db/0x780
 [&lt;ffffffff8106e75b&gt;] worker_thread+0x11b/0x450
 [&lt;ffffffff81073c64&gt;] kthread+0xe4/0x100
 [&lt;ffffffff814cf26c&gt;] ret_from_fork+0x7c/0xb0

See also patch "scsi_transport_srp: Add transport layer error
handling" (commit ID 29c17324803c).

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: James Bottomley &lt;JBottomley@Odin.com&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Sebastian Parschauer &lt;sebastian.riemer@profitbricks.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi_transport_srp: Introduce srp_wait_for_queuecommand()</title>
<updated>2015-07-21T17:10:13+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2015-05-18T11:22:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=618910362d9e666cc76f2eb6280b01e6fb9a6dc3'/>
<id>urn:sha1:618910362d9e666cc76f2eb6280b01e6fb9a6dc3</id>
<content type='text'>
commit be34c62ddf39d1931780b07a6f4241393e4ba2ee upstream.

Introduce the helper function srp_wait_for_queuecommand().
Move the definition of scsi_request_fn_active(). Add a comment
above srp_wait_for_queuecommand() that support for scsi-mq needs
to be added.

This patch does not change any functionality. A second call to
srp_wait_for_queuecommand() will be introduced in the next patch.

Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: James Bottomley &lt;JBottomley@Odin.com&gt;
Cc: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Sebastian Parschauer &lt;sebastian.riemer@profitbricks.com&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipr: Increase default adapter init stage change timeout</title>
<updated>2015-07-21T17:10:11+00:00</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2015-05-13T13:50:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=94179c551d8f340967c3a5ccfda30a83a707d16b'/>
<id>urn:sha1:94179c551d8f340967c3a5ccfda30a83a707d16b</id>
<content type='text'>
commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream.

Increase the default init stage change timeout from 15 seconds to 30 seconds.
This resolves issues we have seen with some adapters not transitioning
to the first init stage within 15 seconds, which results in adapter
initialization failures.

Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sd: Disable support for 256 byte/sector disks</title>
<updated>2015-06-06T15:21:07+00:00</updated>
<author>
<name>Mark Hounschell</name>
<email>dmarkh@cfl.rr.com</email>
</author>
<published>2015-05-13T08:49:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=31522566a4ef965c057b4d909d178d7f5eea4275'/>
<id>urn:sha1:31522566a4ef965c057b4d909d178d7f5eea4275</id>
<content type='text'>
commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.

256 bytes per sector support has been broken since 2.6.X,
and no-one stepped up to fix this.
So disable support for it.

Signed-off-by: Mark Hounschell &lt;dmarkh@cfl.rr.com&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>storvsc: Set the SRB flags correctly when no data transfer is needed</title>
<updated>2015-06-06T15:21:07+00:00</updated>
<author>
<name>K. Y. Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2015-05-01T18:03:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9ee31238f1eebdd27406bd9b6f59c46875ac3081'/>
<id>urn:sha1:9ee31238f1eebdd27406bd9b6f59c46875ac3081</id>
<content type='text'>
commit dc45708ca9988656d706940df5fd102672c5de92 upstream.

Set the SRB flags correctly when there is no data transfer.  Without this
change some IHV drivers will fail valid commands such as TEST_UNIT_READY.

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

</content>
</entry>
<entry>
<title>3w-sas: fix command completion race</title>
<updated>2015-05-13T12:14:29+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-04-23T07:48:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1c6653fd6462e2b0862ca26e5cf358f416594547'/>
<id>urn:sha1:1c6653fd6462e2b0862ca26e5cf358f416594547</id>
<content type='text'>
commit 579d69bc1fd56d5af5761969aa529d1d1c188300 upstream.

The 3w-sas driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point.  Also remove the dma mapping helpers
which have another inherent race due to the request_id index.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reported-by: Torsten Luettgert &lt;ml-lkml@enda.eu&gt;
Tested-by: Bernd Kardatzki &lt;Bernd.Kardatzki@med.uni-tuebingen.de&gt;
Acked-by: Adam Radford &lt;aradford@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>3w-9xxx: fix command completion race</title>
<updated>2015-05-13T12:14:29+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-04-23T07:48:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=457eb9e105684d84b74df66c6365321af1907586'/>
<id>urn:sha1:457eb9e105684d84b74df66c6365321af1907586</id>
<content type='text'>
commit 118c855b5623f3e2e6204f02623d88c09e0c34de upstream.

The 3w-9xxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point.  Also remove the dma mapping helpers
which have another inherent race due to the request_id index.

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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>3w-xxxx: fix command completion race</title>
<updated>2015-05-13T12:14:29+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2015-04-23T07:48:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=65dabc13bb2707d7a04be0b6ed031442f7b18a87'/>
<id>urn:sha1:65dabc13bb2707d7a04be0b6ed031442f7b18a87</id>
<content type='text'>
commit 9cd9554615cba14f0877cc9972a6537ad2bdde61 upstream.

The 3w-xxxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point.  Also remove the dma mapping helpers
which have another inherent race due to the request_id index.

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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: add 1024 max sectors black list flag</title>
<updated>2015-05-13T12:14:29+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.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=df22bc3a3c1acd21baf018ce8405094df306e46f'/>
<id>urn:sha1:df22bc3a3c1acd21baf018ce8405094df306e46f</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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mvsas: fix panic on expander attached SATA devices</title>
<updated>2015-05-06T20:04:00+00:00</updated>
<author>
<name>James Bottomley</name>
<email>JBottomley@Odin.com</email>
</author>
<published>2015-04-16T05:16:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1f77a24829ac6dbe9a942752ee15054d403653d9'/>
<id>urn:sha1:1f77a24829ac6dbe9a942752ee15054d403653d9</id>
<content type='text'>
commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 upstream.

mvsas is giving a General protection fault when it encounters an expander
attached ATA device.  Analysis of mvs_task_prep_ata() shows that the driver is
assuming all ATA devices are locally attached and obtaining the phy mask by
indexing the local phy table (in the HBA structure) with the phy id.  Since
expanders have many more phys than the HBA, this is causing the index into the
HBA phy table to overflow and returning rubbish as the pointer.

mvs_task_prep_ssp() instead does the phy mask using the port properties.
Mirror this in mvs_task_prep_ata() to fix the panic.

Reported-by: Adam Talbot &lt;ajtalbot1@gmail.com&gt;
Tested-by: Adam Talbot &lt;ajtalbot1@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
