<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/scsi, branch v3.4.105</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.105</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.4.105'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2014-12-01T10:02:43+00:00</updated>
<entry>
<title>Fix spurious request sense in error handling</title>
<updated>2014-12-01T10:02:43+00:00</updated>
<author>
<name>James Bottomley</name>
<email>JBottomley@Parallels.com</email>
</author>
<published>2014-03-28T17:50:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=23dd72fe868c722983999aaf13fa4ede1642a322'/>
<id>urn:sha1:23dd72fe868c722983999aaf13fa4ede1642a322</id>
<content type='text'>
commit d555a2abf3481f81303d835046a5ec2c4fb3ca8e upstream.

We unconditionally execute scsi_eh_get_sense() to make sure all failed
commands that should have sense attached, do.  However, the routine forgets
that some commands, because of the way they fail, will not have any sense code
... we should not bother them with a REQUEST_SENSE command.  Fix this by
testing to see if we actually got a CHECK_CONDITION return and skip asking for
sense if we don't.

Tested-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
</entry>
<entry>
<title>libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu</title>
<updated>2014-12-01T10:02:34+00:00</updated>
<author>
<name>Mike Christie</name>
<email>michaelc@cs.wisc.edu</email>
</author>
<published>2014-09-03T05:00:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b559f0bd22b56a1f753a77459b9fade3eebf5077'/>
<id>urn:sha1:b559f0bd22b56a1f753a77459b9fade3eebf5077</id>
<content type='text'>
commit db9bfd64b14a3a8f1868d2164518fdeab1b26ad1 upstream.

This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
This function is used by iscsi drivers and userspace to send iscsi PDUs/
commands. For login commands, we have a set buffer size. For all other
commands we do not support data buffers.

This was reported by Dan Carpenter here:
http://www.spinics.net/lists/linux-scsi/msg66838.html

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Zefan Li &lt;lizefan@huawei.com&gt;
</content>
</entry>
<entry>
<title>scsi: handle flush errors properly</title>
<updated>2014-08-07T19:00:10+00:00</updated>
<author>
<name>James Bottomley</name>
<email>JBottomley@Parallels.com</email>
</author>
<published>2014-07-03T17:17:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0e04ec4d3c1ada2049c9b852ab63fba416c6df8d'/>
<id>urn:sha1:0e04ec4d3c1ada2049c9b852ab63fba416c6df8d</id>
<content type='text'>
commit 89fb4cd1f717a871ef79fa7debbe840e3225cd54 upstream.

Flush commands don't transfer data and thus need to be special cased
in the I/O completion handler so that we can propagate errors to
the block layer and filesystem.

Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Reported-by: Steven Haber &lt;steven@qumulo.com&gt;
Tested-by: Steven Haber &lt;steven@qumulo.com&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>
</entry>
<entry>
<title>sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue</title>
<updated>2014-07-09T17:51:21+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2014-04-09T01:52:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8e51d5ac0181d0b7229536fc7fd4c790865f2cdb'/>
<id>urn:sha1:8e51d5ac0181d0b7229536fc7fd4c790865f2cdb</id>
<content type='text'>
commit fd1232b214af43a973443aec6a2808f16ee5bf70 upstream.

This patch fixes I/O errors with the sym53c8xx_2 driver when the disk
returns QUEUE FULL status.

When the controller encounters an error (including QUEUE FULL or BUSY
status), it aborts all not yet submitted requests in the function
sym_dequeue_from_squeue.

This function aborts them with DID_SOFT_ERROR.

If the disk has full tag queue, the request that caused the overflow is
aborted with QUEUE FULL status (and the scsi midlayer properly retries
it until it is accepted by the disk), but the sym53c8xx_2 driver aborts
the following requests with DID_SOFT_ERROR --- for them, the midlayer
does just a few retries and then signals the error up to sd.

The result is that disk returning QUEUE FULL causes request failures.

The error was reproduced on 53c895 with COMPAQ BD03685A24 disk
(rebranded ST336607LC) with command queue 48 or 64 tags.  The disk has
64 tags, but under some access patterns it return QUEUE FULL when there
are less than 64 pending tags.  The SCSI specification allows returning
QUEUE FULL anytime and it is up to the host to retry.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Cc: Matthew Wilcox &lt;matthew@wil.cx&gt;
Cc: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ibmvscsi: Abort init sequence during error recovery</title>
<updated>2014-07-09T17:51:19+00:00</updated>
<author>
<name>Brian King</name>
<email>brking@linux.vnet.ibm.com</email>
</author>
<published>2014-05-23T15:52:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c4b5ebdfde09bfa83f0b46802fc8c846f072e0f'/>
<id>urn:sha1:7c4b5ebdfde09bfa83f0b46802fc8c846f072e0f</id>
<content type='text'>
commit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream.

If a CRQ reset is triggered for some reason while in the middle
of performing VSCSI adapter initialization, we don't want to
call the done function for the initialization MAD commands as
this will only result in two threads attempting initialization
at the same time, resulting in failures.

Signed-off-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Acked-by: Nathan Fontenot &lt;nfont@linux.vnet.ibm.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: megaraid: Use resource_size_t for PCI resources, not long</title>
<updated>2014-06-16T20:45:46+00:00</updated>
<author>
<name>Ben Collins</name>
<email>ben.c@servergy.com</email>
</author>
<published>2013-09-13T16:46:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4829b8f17cb492cd232da05aeb64db05c74657d6'/>
<id>urn:sha1:4829b8f17cb492cd232da05aeb64db05c74657d6</id>
<content type='text'>
commit 11f8a7b31f2140b0dc164bb484281235ffbe51d3 upstream.

The assumption that sizeof(long) &gt;= sizeof(resource_size_t) can lead to
truncation of the PCI resource address, meaning this driver didn't work
on 32-bit systems with 64-bit PCI adressing ranges.

Signed-off-by: Ben Collins &lt;ben.c@servergy.com&gt;
Acked-by: Sumit Saxena &lt;sumit.saxena@lsi.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>hpsa: gen8plus Smart Array IDs</title>
<updated>2014-06-11T19:04:20+00:00</updated>
<author>
<name>Mike Miller</name>
<email>mike.miller@hp.com</email>
</author>
<published>2012-09-20T21:05:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=437569c5bdfb172fd13d27a82c108724b674bd63'/>
<id>urn:sha1:437569c5bdfb172fd13d27a82c108724b674bd63</id>
<content type='text'>
commit fe0c9610bb68dd0aad1017456f5e3c31264d70c2 upstream.

Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Rui Xiang &lt;rui.xiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mpt2sas: Fix for issue Missing delay not getting set during system bootup</title>
<updated>2014-06-11T19:04:20+00:00</updated>
<author>
<name>Reddy, Sreekanth</name>
<email>Sreekanth.Reddy@lsi.com</email>
</author>
<published>2013-02-26T11:29:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0bf3ffd5075b92bf04975c18a44baceab06a848d'/>
<id>urn:sha1:0bf3ffd5075b92bf04975c18a44baceab06a848d</id>
<content type='text'>
commit 93cfcb8c998e3fe2c075fa61ab28f7b018e5049a upstream.

commit b0df96a0068daee4f9c2189c29b9053eb6e46b17 upstream.

Missing delay is not getting set properly. The reason is that it is not
defined in the same file from where it is being invoked.  The fix is to move
the missing delay module parameter from mpt2sas_base.c to mpt2sas_scsh.c.

Signed-off-by: Sreekanth Reddy &lt;Sreekanth.Reddy@lsi.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Rui Xiang &lt;rui.xiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mpt2sas: Fix for device scan following host reset could get stuck in a infinite loop</title>
<updated>2014-06-11T19:04:20+00:00</updated>
<author>
<name>Sreekanth Reddy</name>
<email>Sreekanth.Reddy@lsi.com</email>
</author>
<published>2013-02-01T19:26:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ce7035a6fdded27ad961445f6796a57b9bef04bf'/>
<id>urn:sha1:ce7035a6fdded27ad961445f6796a57b9bef04bf</id>
<content type='text'>
commit 6241f22ca12a26ee149cbe31b27bac97dbdc8bc4 upstream.

Modified device scan routine so each configuration page read breaks from the
while loop when the ioc_status is not equal to MPI2_IOCSTATUS_SUCCESS.

[jejb: checkpatch fixes]
Signed-off-by: Sreekanth Reddy &lt;Sreekanth.Reddy@lsi.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
[bwh: Backported to 3.2; adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Rui Xiang &lt;rui.xiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>isci: Fix a race condition in the SSP task management path</title>
<updated>2014-06-11T19:04:20+00:00</updated>
<author>
<name>Jeff Skirvin</name>
<email>jeffrey.d.skirvin@intel.com</email>
</author>
<published>2013-07-12T00:18:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=21b40f509a80e8446748329d9436c8ebffff27de'/>
<id>urn:sha1:21b40f509a80e8446748329d9436c8ebffff27de</id>
<content type='text'>
commit 96f15f29038e58e1b0a96483e2b369ff446becf1 upstream.

This commit fixes a race condition in the isci driver abort task and SSP
device task management path.  The race is caused when an I/O termination
in the SCU hardware is necessary because of an SSP target timeout condition,
and the check of the I/O end state races against the HW-termination-driven
end state.  The failure of the race meant that no TMF was sent to the device
to clean-up the pending I/O.

Signed-off-by: Jeff Skirvin &lt;jeffrey.d.skirvin@intel.com&gt;
Reviewed-by: Lukasz Dorau &lt;lukasz.dorau@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Rui Xiang &lt;rui.xiang@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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