<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/scsi, branch v4.14-rc4</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2017-10-07T19:34:16+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-10-07T19:34:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=85b1bb248071967135d22cc84e62292094f4a3c6'/>
<id>85b1bb248071967135d22cc84e62292094f4a3c6</id>
<content type='text'>
Pull SCSI fixes from James Bottomley:

 - a couple of serious fixes: use after free and blacklist for WRITE
   SAME

 - one error leg fix: write_pending failure

 - one user experience problem: do not override max_sectors_kb

 - one minor unused function removal

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: ibmvscsis: Fix write_pending failure path
  scsi: libiscsi: Remove iscsi_destroy_session
  scsi: libiscsi: Fix use-after-free race during iscsi_session_teardown
  scsi: sd: Do not override max_sectors_kb sysfs setting
  scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull SCSI fixes from James Bottomley:

 - a couple of serious fixes: use after free and blacklist for WRITE
   SAME

 - one error leg fix: write_pending failure

 - one user experience problem: do not override max_sectors_kb

 - one minor unused function removal

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: ibmvscsis: Fix write_pending failure path
  scsi: libiscsi: Remove iscsi_destroy_session
  scsi: libiscsi: Fix use-after-free race during iscsi_session_teardown
  scsi: sd: Do not override max_sectors_kb sysfs setting
  scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: ibmvscsis: Fix write_pending failure path</title>
<updated>2017-10-03T02:49:27+00:00</updated>
<author>
<name>Bryant G. Ly</name>
<email>bgly@us.ibm.com</email>
</author>
<published>2017-10-02T17:59:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=88e65389fce1f68ba6d13ae2fc0f8d7e5c338c52'/>
<id>88e65389fce1f68ba6d13ae2fc0f8d7e5c338c52</id>
<content type='text'>
For write_pending if the queue is down or client failed then return -EIO
so that LIO can properly process the completed command. Prior we
returned 0 since LIO could not handle it properly. Now with commit
fa7e25cf13a6 ("target: Fix unknown fabric callback queue-full errors")
that patch addresses LIO's ability to handle things right.

Signed-off-by: Bryant G. Ly &lt;bgly@us.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For write_pending if the queue is down or client failed then return -EIO
so that LIO can properly process the completed command. Prior we
returned 0 since LIO could not handle it properly. Now with commit
fa7e25cf13a6 ("target: Fix unknown fabric callback queue-full errors")
that patch addresses LIO's ability to handle things right.

Signed-off-by: Bryant G. Ly &lt;bgly@us.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: libiscsi: Remove iscsi_destroy_session</title>
<updated>2017-10-03T02:23:21+00:00</updated>
<author>
<name>Khazhismel Kumykov</name>
<email>khazhy@google.com</email>
</author>
<published>2017-07-13T16:11:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1c048a250aae1aaab0ba9dbec908f0c6cdb8614f'/>
<id>1c048a250aae1aaab0ba9dbec908f0c6cdb8614f</id>
<content type='text'>
iscsi_session_teardown was the only user of this function. Function
currently is just short for iscsi_remove_session + iscsi_free_session.

Signed-off-by: Khazhismel Kumykov &lt;khazhy@google.com&gt;
Acked-by: Chris Leech &lt;cleech@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
iscsi_session_teardown was the only user of this function. Function
currently is just short for iscsi_remove_session + iscsi_free_session.

Signed-off-by: Khazhismel Kumykov &lt;khazhy@google.com&gt;
Acked-by: Chris Leech &lt;cleech@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: libiscsi: Fix use-after-free race during iscsi_session_teardown</title>
<updated>2017-10-03T02:23:21+00:00</updated>
<author>
<name>Khazhismel Kumykov</name>
<email>khazhy@google.com</email>
</author>
<published>2017-07-13T16:11:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9e10b5121ad991ea6e84ca40b15a04cdc551bfe9'/>
<id>9e10b5121ad991ea6e84ca40b15a04cdc551bfe9</id>
<content type='text'>
Session attributes exposed through sysfs were freed before the device
was destroyed, resulting in a potential use-after-free. Free these
attributes after removing the device.

Signed-off-by: Khazhismel Kumykov &lt;khazhy@google.com&gt;
Acked-by: Chris Leech &lt;cleech@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Session attributes exposed through sysfs were freed before the device
was destroyed, resulting in a potential use-after-free. Free these
attributes after removing the device.

Signed-off-by: Khazhismel Kumykov &lt;khazhy@google.com&gt;
Acked-by: Chris Leech &lt;cleech@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: sd: Do not override max_sectors_kb sysfs setting</title>
<updated>2017-10-03T02:16:25+00:00</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2017-09-28T01:38:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=77082ca503bed061f7fbda7cfd7c93beda967a41'/>
<id>77082ca503bed061f7fbda7cfd7c93beda967a41</id>
<content type='text'>
A user may lower the max_sectors_kb setting in sysfs to accommodate
certain workloads. Previously we would always set the max I/O size to
either the block layer default or the optional preferred I/O size
reported by the device.

Keep the current heuristics for the initial setting of max_sectors_kb.
For subsequent invocations, only update the current queue limit if it
exceeds the capabilities of the hardware.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Don Brace &lt;don.brace@microsemi.com&gt;
Reviewed-by: Martin Wilck &lt;mwilck@suse.com&gt;
Tested-by: Don Brace &lt;don.brace@microsemi.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A user may lower the max_sectors_kb setting in sysfs to accommodate
certain workloads. Previously we would always set the max I/O size to
either the block layer default or the optional preferred I/O size
reported by the device.

Keep the current heuristics for the initial setting of max_sectors_kb.
For subsequent invocations, only update the current queue limit if it
exceeds the capabilities of the hardware.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Don Brace &lt;don.brace@microsemi.com&gt;
Reviewed-by: Martin Wilck &lt;mwilck@suse.com&gt;
Tested-by: Don Brace &lt;don.brace@microsemi.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP</title>
<updated>2017-10-03T02:16:18+00:00</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2017-09-28T01:35:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=28a0bc4120d38a394499382ba21d6965a67a3703'/>
<id>28a0bc4120d38a394499382ba21d6965a67a3703</id>
<content type='text'>
SBC-4 states:

  "A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates the
   maximum number of LBAs that may be unmapped by an UNMAP command"

  "A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates
   the maximum number of contiguous logical blocks that the device server
   allows to be unmapped or written in a single WRITE SAME command."

Despite the spec being clear on the topic, some devices incorrectly
expect WRITE SAME commands with the UNMAP bit set to be limited to the
value reported in MAXIMUM UNMAP LBA COUNT in the Block Limits VPD.

Implement a blacklist option that can be used to accommodate devices
with this behavior.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Bill Kuzeja &lt;William.Kuzeja@stratus.com&gt;
Reported-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Tested-by: Laurence Oberman &lt;loberman@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SBC-4 states:

  "A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates the
   maximum number of LBAs that may be unmapped by an UNMAP command"

  "A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates
   the maximum number of contiguous logical blocks that the device server
   allows to be unmapped or written in a single WRITE SAME command."

Despite the spec being clear on the topic, some devices incorrectly
expect WRITE SAME commands with the UNMAP bit set to be limited to the
value reported in MAXIMUM UNMAP LBA COUNT in the Block Limits VPD.

Implement a blacklist option that can be used to accommodate devices
with this behavior.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Bill Kuzeja &lt;William.Kuzeja@stratus.com&gt;
Reported-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Tested-by: Laurence Oberman &lt;loberman@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2017-09-30T19:50:56+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-09-30T19:50:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0b33ce72ea8834e41174c728845eee1c526d6f88'/>
<id>0b33ce72ea8834e41174c728845eee1c526d6f88</id>
<content type='text'>
Pull SCSI fixes from James Bottomley:
 "Eight mostly minor fixes for recently discovered issues in drivers"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: ILLEGAL REQUEST + ASC==27 =&gt; target failure
  scsi: aacraid: Add a small delay after IOP reset
  scsi: scsi_transport_fc: Also check for NOTPRESENT in fc_remote_port_add()
  scsi: scsi_transport_fc: set scsi_target_id upon rescan
  scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly
  scsi: aacraid: error: testing array offset 'bus' after use
  scsi: lpfc: Don't return internal MBXERR_ERROR code from probe function
  scsi: aacraid: Fix 2T+ drives on SmartIOC-2000
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull SCSI fixes from James Bottomley:
 "Eight mostly minor fixes for recently discovered issues in drivers"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: ILLEGAL REQUEST + ASC==27 =&gt; target failure
  scsi: aacraid: Add a small delay after IOP reset
  scsi: scsi_transport_fc: Also check for NOTPRESENT in fc_remote_port_add()
  scsi: scsi_transport_fc: set scsi_target_id upon rescan
  scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly
  scsi: aacraid: error: testing array offset 'bus' after use
  scsi: lpfc: Don't return internal MBXERR_ERROR code from probe function
  scsi: aacraid: Fix 2T+ drives on SmartIOC-2000
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: ILLEGAL REQUEST + ASC==27 =&gt; target failure</title>
<updated>2017-09-28T01:55:21+00:00</updated>
<author>
<name>Martin Wilck</name>
<email>mwilck@suse.com</email>
</author>
<published>2017-09-27T12:44:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d0b7a9095c0730b92a0a2eecaba2e6b77ed87339'/>
<id>d0b7a9095c0730b92a0a2eecaba2e6b77ed87339</id>
<content type='text'>
ASC 0x27 is "WRITE PROTECTED". This error code is returned e.g.  by
Fujitsu ETERNUS systems under certain conditions for WRITE SAME 16
commands with UNMAP bit set. It should not be treated as a path
error. In general, it makes sense to assume that being write protected
is a target rather than a path property.

Signed-off-by: Martin Wilck &lt;mwilck@suse.com&gt;
Acked-by: Lee Duncan &lt;lduncan@suse.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ASC 0x27 is "WRITE PROTECTED". This error code is returned e.g.  by
Fujitsu ETERNUS systems under certain conditions for WRITE SAME 16
commands with UNMAP bit set. It should not be treated as a path
error. In general, it makes sense to assume that being write protected
is a target rather than a path property.

Signed-off-by: Martin Wilck &lt;mwilck@suse.com&gt;
Acked-by: Lee Duncan &lt;lduncan@suse.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: aacraid: Add a small delay after IOP reset</title>
<updated>2017-09-28T01:42:14+00:00</updated>
<author>
<name>Guilherme G. Piccoli</name>
<email>gpiccoli@linux.vnet.ibm.com</email>
</author>
<published>2017-09-19T15:11:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d1b490939d8c117a06dfc562c41d933f71d30289'/>
<id>d1b490939d8c117a06dfc562c41d933f71d30289</id>
<content type='text'>
Commit 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset
status") changed the way driver checks if a reset succeeded. Now, after an
IOP reset, aacraid immediately start polling a register to verify the reset
is complete.

This behavior cause regressions on the reset path in PowerPC (at least).
Since the delay after the IOP reset was removed by the aforementioned patch,
the fact driver just starts to read a register instantly after the reset
was issued (by writing in another register) "corrupts" the reset procedure,
which ends up failing all the time.

The issue highly impacted kdump on PowerPC, since on kdump path we
proactively issue a reset in adapter (through the reset_devices kernel
parameter).

This patch (re-)adds a delay right after IOP reset is issued. Empirically
we measured that 3 seconds is enough, but for safety reasons we delay
for 5s (and since it was 30s before, 5s is still a small amount).

For reference, without this patch we observe the following messages
on kdump kernel boot process:

  [ 76.294] aacraid 0003:01:00.0: IOP reset failed
  [ 76.294] aacraid 0003:01:00.0: ARC Reset attempt failed
  [ 86.524] aacraid 0003:01:00.0: adapter kernel panic'd ff.
  [ 86.524] aacraid 0003:01:00.0: Controller reset type is 3
  [ 86.524] aacraid 0003:01:00.0: Issuing IOP reset
  [146.534] aacraid 0003:01:00.0: IOP reset failed
  [146.534] aacraid 0003:01:00.0: ARC Reset attempt failed

Fixes: 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset status")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Acked-by: Dave Carroll &lt;david.carroll@microsemi.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset
status") changed the way driver checks if a reset succeeded. Now, after an
IOP reset, aacraid immediately start polling a register to verify the reset
is complete.

This behavior cause regressions on the reset path in PowerPC (at least).
Since the delay after the IOP reset was removed by the aforementioned patch,
the fact driver just starts to read a register instantly after the reset
was issued (by writing in another register) "corrupts" the reset procedure,
which ends up failing all the time.

The issue highly impacted kdump on PowerPC, since on kdump path we
proactively issue a reset in adapter (through the reset_devices kernel
parameter).

This patch (re-)adds a delay right after IOP reset is issued. Empirically
we measured that 3 seconds is enough, but for safety reasons we delay
for 5s (and since it was 30s before, 5s is still a small amount).

For reference, without this patch we observe the following messages
on kdump kernel boot process:

  [ 76.294] aacraid 0003:01:00.0: IOP reset failed
  [ 76.294] aacraid 0003:01:00.0: ARC Reset attempt failed
  [ 86.524] aacraid 0003:01:00.0: adapter kernel panic'd ff.
  [ 86.524] aacraid 0003:01:00.0: Controller reset type is 3
  [ 86.524] aacraid 0003:01:00.0: Issuing IOP reset
  [146.534] aacraid 0003:01:00.0: IOP reset failed
  [146.534] aacraid 0003:01:00.0: ARC Reset attempt failed

Fixes: 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset status")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Guilherme G. Piccoli &lt;gpiccoli@linux.vnet.ibm.com&gt;
Acked-by: Dave Carroll &lt;david.carroll@microsemi.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: scsi_transport_fc: Also check for NOTPRESENT in fc_remote_port_add()</title>
<updated>2017-09-26T01:34:09+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2017-09-25T11:47:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f091fb8c344ce13cbf058d304c6cbb042be97058'/>
<id>f091fb8c344ce13cbf058d304c6cbb042be97058</id>
<content type='text'>
During failover there is a small race window between fc_remote_port_add()
and fc_timeout_deleted_rport(); the latter drops the lock after setting the
port to NOTPRESENT, so if fc_remote_port_add() is called right at that time
it will fail to detect the existing rport and happily adding a new
structure, causing rports to get registered twice.

Signed-off-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During failover there is a small race window between fc_remote_port_add()
and fc_timeout_deleted_rport(); the latter drops the lock after setting the
port to NOTPRESENT, so if fc_remote_port_add() is called right at that time
it will fail to detect the existing rport and happily adding a new
structure, causing rports to get registered twice.

Signed-off-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
