<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/scsi, branch linux-2.6.33.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>libsas: set sas_address and device type of rphy</title>
<updated>2011-11-07T21:47:12+00:00</updated>
<author>
<name>Jack Wang</name>
<email>jack_wang@usish.com</email>
</author>
<published>2011-09-23T06:32:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=32b7ba7b018e2da23eff126a6307710307a65773'/>
<id>32b7ba7b018e2da23eff126a6307710307a65773</id>
<content type='text'>
commit bb041a0e9c31229071b6e56e1d0d8374af0d2038 upstream.

Libsas forget to set the sas_address and device type of rphy lead to file
under /sys/class/sas_x show wrong value, fix that.

Signed-off-by: Jack Wang &lt;jack_wang@usish.com&gt;
Tested-by: Crystal Yu &lt;crystal_yu@usish.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

Libsas forget to set the sas_address and device type of rphy lead to file
under /sys/class/sas_x show wrong value, fix that.

Signed-off-by: Jack Wang &lt;jack_wang@usish.com&gt;
Tested-by: Crystal Yu &lt;crystal_yu@usish.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipr: Always initiate hard reset in kdump kernel</title>
<updated>2011-11-07T21:47:12+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@samba.org</email>
</author>
<published>2011-08-01T09:43:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=52eb192b554b5535f85f8f666e5cabacf40733fb'/>
<id>52eb192b554b5535f85f8f666e5cabacf40733fb</id>
<content type='text'>
commit 5d7c20b7fa5c6ca19e871b4050e321c99d32bd43 upstream.

During kdump testing I noticed timeouts when initialising each IPR
adapter. While the driver has logic to detect an adapter in an
indeterminate state, it wasn't triggering and each adapter went
through a 5 minute timeout before finally going operational.

Some analysis showed the needs_hard_reset flag wasn't getting set.
We can check the reset_devices kernel parameter which is set by
kdump and force a full reset. This fixes the problem.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Acked-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

During kdump testing I noticed timeouts when initialising each IPR
adapter. While the driver has logic to detect an adapter in an
indeterminate state, it wasn't triggering and each adapter went
through a 5 minute timeout before finally going operational.

Some analysis showed the needs_hard_reset flag wasn't getting set.
We can check the reset_devices kernel parameter which is set by
kdump and force a full reset. This fixes the problem.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Acked-by: Brian King &lt;brking@linux.vnet.ibm.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libsas: fix panic when single phy is disabled on a wide port</title>
<updated>2011-11-07T21:47:06+00:00</updated>
<author>
<name>Mark Salyzyn</name>
<email>mark_salyzyn@us.xyratex.com</email>
</author>
<published>2011-09-22T15:32:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=719ec0da4043a1520190de771f91c17ea5967b71'/>
<id>719ec0da4043a1520190de771f91c17ea5967b71</id>
<content type='text'>
commit a73914c35b05d80f8ce78288e10056c91090b666 upstream.

When a wide port is being utilized to a target, if one disables only one
of the
phys, we get an OS crash:

BUG: unable to handle kernel NULL pointer dereference at
0000000000000238
IP: [&lt;ffffffff814ca9b1&gt;] mutex_lock+0x21/0x50
PGD 4103f5067 PUD 41dba9067 PMD 0
Oops: 0002 [#1] SMP
last sysfs file: /sys/bus/pci/slots/5/address
CPU 0
Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]

Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]
Pid: 5146, comm: scsi_wq_5 Not tainted
2.6.32-71.29.1.el6.lustre.7.x86_64 #1 Storage Server
RIP: 0010:[&lt;ffffffff814ca9b1&gt;]  [&lt;ffffffff814ca9b1&gt;]
mutex_lock+0x21/0x50
RSP: 0018:ffff8803e4e33d30  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000238 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8803e664c800 RDI: 0000000000000238
RBP: ffff8803e4e33d40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000238 R14: ffff88041acb7200 R15: ffff88041c51ada0
FS:  0000000000000000(0000) GS:ffff880028200000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000238 CR3: 0000000410143000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process scsi_wq_5 (pid: 5146, threadinfo ffff8803e4e32000, task
ffff8803e4e294a0)
Stack:
 ffff8803e664c800 0000000000000000 ffff8803e4e33d70 ffffffffa001f06e
&lt;0&gt; ffff8803e4e33d60 ffff88041c51ada0 ffff88041acb7200 ffff88041bc0aa00
&lt;0&gt; ffff8803e4e33d90 ffffffffa0032b6c 0000000000000014 ffff88041acb7200
Call Trace:
 [&lt;ffffffffa001f06e&gt;] sas_port_delete_phy+0x2e/0xa0 [scsi_transport_sas]
 [&lt;ffffffffa0032b6c&gt;] sas_unregister_devs_sas_addr+0xac/0xe0 [libsas]
 [&lt;ffffffffa0034914&gt;] sas_ex_revalidate_domain+0x204/0x330 [libsas]
 [&lt;ffffffffa00307f0&gt;] ? sas_revalidate_domain+0x0/0x90 [libsas]
 [&lt;ffffffffa0030855&gt;] sas_revalidate_domain+0x65/0x90 [libsas]
 [&lt;ffffffff8108c7d0&gt;] worker_thread+0x170/0x2a0
 [&lt;ffffffff81091ea0&gt;] ? autoremove_wake_function+0x0/0x40
 [&lt;ffffffff8108c660&gt;] ? worker_thread+0x0/0x2a0
 [&lt;ffffffff81091b36&gt;] kthread+0x96/0xa0
 [&lt;ffffffff810141ca&gt;] child_rip+0xa/0x20
 [&lt;ffffffff81091aa0&gt;] ? kthread+0x0/0xa0
 [&lt;ffffffff810141c0&gt;] ? child_rip+0x0/0x20
Code: ff ff 85 c0 75 ed eb d6 66 90 55 48 89 e5 48 83 ec 10 48 89 1c 24
4c 89 64 24 08 0f 1f 44 00 00 48 89 fb e8 92 f4 ff ff 48 89 df &lt;f0&gt; ff
0f 79 05 e8 25 00 00 00 65 48 8b 04 25 08 cc 00 00 48 2d
RIP  [&lt;ffffffff814ca9b1&gt;] mutex_lock+0x21/0x50
 RSP &lt;ffff8803e4e33d30&gt;
CR2: 0000000000000238

The following patch is admittedly a band-aid, and does not solve the
root cause, but it still is a good candidate for hardening as a pointer
check before reference.

Signed-off-by: Mark Salyzyn &lt;mark_salyzyn@us.xyratex.com&gt;
Tested-by: Jack Wang &lt;jack_wang@usish.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

When a wide port is being utilized to a target, if one disables only one
of the
phys, we get an OS crash:

BUG: unable to handle kernel NULL pointer dereference at
0000000000000238
IP: [&lt;ffffffff814ca9b1&gt;] mutex_lock+0x21/0x50
PGD 4103f5067 PUD 41dba9067 PMD 0
Oops: 0002 [#1] SMP
last sysfs file: /sys/bus/pci/slots/5/address
CPU 0
Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]

Modules linked in: pm8001(U) ses enclosure fuse nfsd exportfs autofs4
ipmi_devintf ipmi_si ipmi_msghandler nfs lockd fscache nfs_acl
auth_rpcgss 8021q fcoe libfcoe garp libfc scsi_transport_fc stp scsi_tgt
llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 sr_mod cdrom
dm_mirror dm_region_hash dm_log uinput sg i2c_i801 i2c_core iTCO_wdt
iTCO_vendor_support e1000e mlx4_ib ib_mad ib_core mlx4_en mlx4_core ext3
jbd mbcache sd_mod crc_t10dif usb_storage ata_generic pata_acpi ata_piix
libsas(U) scsi_transport_sas dm_mod [last unloaded: pm8001]
Pid: 5146, comm: scsi_wq_5 Not tainted
2.6.32-71.29.1.el6.lustre.7.x86_64 #1 Storage Server
RIP: 0010:[&lt;ffffffff814ca9b1&gt;]  [&lt;ffffffff814ca9b1&gt;]
mutex_lock+0x21/0x50
RSP: 0018:ffff8803e4e33d30  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000238 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8803e664c800 RDI: 0000000000000238
RBP: ffff8803e4e33d40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000238 R14: ffff88041acb7200 R15: ffff88041c51ada0
FS:  0000000000000000(0000) GS:ffff880028200000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000238 CR3: 0000000410143000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process scsi_wq_5 (pid: 5146, threadinfo ffff8803e4e32000, task
ffff8803e4e294a0)
Stack:
 ffff8803e664c800 0000000000000000 ffff8803e4e33d70 ffffffffa001f06e
&lt;0&gt; ffff8803e4e33d60 ffff88041c51ada0 ffff88041acb7200 ffff88041bc0aa00
&lt;0&gt; ffff8803e4e33d90 ffffffffa0032b6c 0000000000000014 ffff88041acb7200
Call Trace:
 [&lt;ffffffffa001f06e&gt;] sas_port_delete_phy+0x2e/0xa0 [scsi_transport_sas]
 [&lt;ffffffffa0032b6c&gt;] sas_unregister_devs_sas_addr+0xac/0xe0 [libsas]
 [&lt;ffffffffa0034914&gt;] sas_ex_revalidate_domain+0x204/0x330 [libsas]
 [&lt;ffffffffa00307f0&gt;] ? sas_revalidate_domain+0x0/0x90 [libsas]
 [&lt;ffffffffa0030855&gt;] sas_revalidate_domain+0x65/0x90 [libsas]
 [&lt;ffffffff8108c7d0&gt;] worker_thread+0x170/0x2a0
 [&lt;ffffffff81091ea0&gt;] ? autoremove_wake_function+0x0/0x40
 [&lt;ffffffff8108c660&gt;] ? worker_thread+0x0/0x2a0
 [&lt;ffffffff81091b36&gt;] kthread+0x96/0xa0
 [&lt;ffffffff810141ca&gt;] child_rip+0xa/0x20
 [&lt;ffffffff81091aa0&gt;] ? kthread+0x0/0xa0
 [&lt;ffffffff810141c0&gt;] ? child_rip+0x0/0x20
Code: ff ff 85 c0 75 ed eb d6 66 90 55 48 89 e5 48 83 ec 10 48 89 1c 24
4c 89 64 24 08 0f 1f 44 00 00 48 89 fb e8 92 f4 ff ff 48 89 df &lt;f0&gt; ff
0f 79 05 e8 25 00 00 00 65 48 8b 04 25 08 cc 00 00 48 2d
RIP  [&lt;ffffffff814ca9b1&gt;] mutex_lock+0x21/0x50
 RSP &lt;ffff8803e4e33d30&gt;
CR2: 0000000000000238

The following patch is admittedly a band-aid, and does not solve the
root cause, but it still is a good candidate for hardening as a pointer
check before reference.

Signed-off-by: Mark Salyzyn &lt;mark_salyzyn@us.xyratex.com&gt;
Tested-by: Jack Wang &lt;jack_wang@usish.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libsas: fix failure to revalidate domain for anything but the first expander child.</title>
<updated>2011-11-07T21:47:05+00:00</updated>
<author>
<name>Mark Salyzyn</name>
<email>mark_salyzyn@us.xyratex.com</email>
</author>
<published>2011-09-01T13:11:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8608c3131f166b628f6ccd49d508b682adc95827'/>
<id>8608c3131f166b628f6ccd49d508b682adc95827</id>
<content type='text'>
commit 24926dadc41cc566e974022b0e66231b82c6375f upstream.

In an enclosure model where there are chaining expanders to a large body
of storage, it was discovered that libsas, responding to a broadcast
event change, would only revalidate the domain of first child expander
in the list.

The issue is that the pointer value to the discovered source device was
used to break out of the loop, rather than the content of the pointer.

This still remains non-compliant as the revalidate domain code is
supposed to loop through all child expanders, and not stop at the first
one it finds that reports a change count. However, the design of this
routine does not allow multiple device discoveries and that would be a
more complicated set of patches reserved for another day. We are fixing
the glaring bug rather than refactoring the code.

Signed-off-by: Mark Salyzyn &lt;msalyzyn@us.xyratex.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

In an enclosure model where there are chaining expanders to a large body
of storage, it was discovered that libsas, responding to a broadcast
event change, would only revalidate the domain of first child expander
in the list.

The issue is that the pointer value to the discovered source device was
used to break out of the loop, rather than the content of the pointer.

This still remains non-compliant as the revalidate domain code is
supposed to loop through all child expanders, and not stop at the first
one it finds that reports a change count. However, the design of this
routine does not allow multiple device discoveries and that would be a
more complicated set of patches reserved for another day. We are fixing
the glaring bug rather than refactoring the code.

Signed-off-by: Mark Salyzyn &lt;msalyzyn@us.xyratex.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>aacraid: reset should disable MSI interrupt</title>
<updated>2011-11-07T21:47:04+00:00</updated>
<author>
<name>Vasily Averin</name>
<email>vvs@parallels.com</email>
</author>
<published>2011-09-02T15:31:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9be0982623b4fd490bf0933da891f13a3a90807d'/>
<id>9be0982623b4fd490bf0933da891f13a3a90807d</id>
<content type='text'>
commit d0efab26f89506387a1bde898556660e06d7eb15 upstream.

scsi reset on hardware with enabled MSI interrupts generates WARNING message

[11027.798722] aacraid: Host adapter abort request (0,0,0,0)
[11027.798814] aacraid: Host adapter reset request. SCSI hang ?
[11087.762237] aacraid: SCSI bus appears hung
[11135.082543] ------------[ cut here ]------------
[11135.082646] WARNING: at drivers/pci/msi.c:658 pci_enable_msi_block+0x251/0x290()

Signed-off-by: Vasily Averin &lt;vvs@sw.ru&gt;
Acked-by: Mark Salyzyn &lt;mark_salyzyn@us.xyratex.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

scsi reset on hardware with enabled MSI interrupts generates WARNING message

[11027.798722] aacraid: Host adapter abort request (0,0,0,0)
[11027.798814] aacraid: Host adapter reset request. SCSI hang ?
[11087.762237] aacraid: SCSI bus appears hung
[11135.082543] ------------[ cut here ]------------
[11135.082646] WARNING: at drivers/pci/msi.c:658 pci_enable_msi_block+0x251/0x290()

Signed-off-by: Vasily Averin &lt;vvs@sw.ru&gt;
Acked-by: Mark Salyzyn &lt;mark_salyzyn@us.xyratex.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>3w-9xxx: fix iommu_iova leak</title>
<updated>2011-11-07T21:47:03+00:00</updated>
<author>
<name>James Bottomley</name>
<email>JBottomley@Parallels.com</email>
</author>
<published>2011-09-18T14:56:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bdddc16bc99fe08e182b71634319ad77bfb356fc'/>
<id>bdddc16bc99fe08e182b71634319ad77bfb356fc</id>
<content type='text'>
commit 96067723e46b0dd24ae7b934085ab4eff4d26a1b upstream.

Following reports on the list, it looks like the 3e-9xxx driver will leak dma
mappings every time we get a transient queueing error back from the card.
This is because it maps the sg list in the routine that sends the command, but
doesn't unmap again in the transient failure path (even though the command is
sent back to the block layer).  Fix by unmapping before returning the status.

Reported-by: Chris Boot &lt;bootc@bootc.net&gt;
Tested-by: Chris Boot &lt;bootc@bootc.net&gt;
Acked-by: Adam Radford &lt;aradford@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

Following reports on the list, it looks like the 3e-9xxx driver will leak dma
mappings every time we get a transient queueing error back from the card.
This is because it maps the sg list in the routine that sends the command, but
doesn't unmap again in the transient failure path (even though the command is
sent back to the block layer).  Fix by unmapping before returning the status.

Reported-by: Chris Boot &lt;bootc@bootc.net&gt;
Tested-by: Chris Boot &lt;bootc@bootc.net&gt;
Acked-by: Adam Radford &lt;aradford@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libiscsi_tcp: fix LLD data allocation</title>
<updated>2011-11-07T21:47:01+00:00</updated>
<author>
<name>Mike Christie</name>
<email>michaelc@cs.wisc.edu</email>
</author>
<published>2011-06-24T20:11:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d5893723e57f33454ece7ab473a3352f6913af19'/>
<id>d5893723e57f33454ece7ab473a3352f6913af19</id>
<content type='text'>
commit 74dcd0ec735ba9c5bef254b2f6e53068cf3f9ff0 upstream.

Have libiscsi_tcp have upper layers allocate the LLD data
along with the iscsi_cls_conn struct, so it is refcounted.

Signed-off-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

Have libiscsi_tcp have upper layers allocate the LLD data
along with the iscsi_cls_conn struct, so it is refcounted.

Signed-off-by: Mike Christie &lt;michaelc@cs.wisc.edu&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>fcoe: Unable to select the exchangeID from offload pool for storage targets</title>
<updated>2011-11-07T21:46:58+00:00</updated>
<author>
<name>Kiran Patil</name>
<email>kiran.patil@intel.com</email>
</author>
<published>2011-06-20T23:59:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bb116e4754275c768158e5ab799f9b8c25ca02a0'/>
<id>bb116e4754275c768158e5ab799f9b8c25ca02a0</id>
<content type='text'>
commit 1ff9918b625457ce20d450d00f9ed0a12ba191b7 upstream.

Problem: When initiator sends write command to target, target tries to
assign new sequence. It allocates new exchangeID (RX_ID)
always from non-offloaded pool (Non-offload EMA)

Fix: Enhanced fcoe_oem_match routine to look at F_CTL flags and if it
is exchange responder and command type is WRITEDATA, then function
returns TRUE instead of FALSE. This function is used to determine
which pool to use (offload pool of exchange is used only if this
function returns TRUE).

Technical Notes: N/A

Signed-off-by: Kiran Patil &lt;kiran.patil@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

Problem: When initiator sends write command to target, target tries to
assign new sequence. It allocates new exchangeID (RX_ID)
always from non-offloaded pool (Non-offload EMA)

Fix: Enhanced fcoe_oem_match routine to look at F_CTL flags and if it
is exchange responder and command type is WRITEDATA, then function
returns TRUE instead of FALSE. This function is used to determine
which pool to use (offload pool of exchange is used only if this
function returns TRUE).

Technical Notes: N/A

Signed-off-by: Kiran Patil &lt;kiran.patil@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>qla2xxx: Correct inadvertent loop state transitions during port-update handling.</title>
<updated>2011-11-07T21:46:52+00:00</updated>
<author>
<name>Andrew Vasquez</name>
<email>andrew.vasquez@qlogic.com</email>
</author>
<published>2011-08-16T18:29:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cfbd9b3df144c42a5ad752bc9aafa7db3947147e'/>
<id>cfbd9b3df144c42a5ad752bc9aafa7db3947147e</id>
<content type='text'>
commit 58b48576966ed0afd3f63ef17480ec12748a7119 upstream.

Transitioning to a LOOP_UPDATE loop-state could cause the driver
to miss normal link/target processing.  LOOP_UPDATE is a crufty
artifact leftover from at time the driver performed it's own
internal command-queuing.  Safely remove this state.

Signed-off-by: Andrew Vasquez &lt;andrew.vasquez@qlogic.com&gt;
Signed-off-by: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;

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

Transitioning to a LOOP_UPDATE loop-state could cause the driver
to miss normal link/target processing.  LOOP_UPDATE is a crufty
artifact leftover from at time the driver performed it's own
internal command-queuing.  Safely remove this state.

Signed-off-by: Andrew Vasquez &lt;andrew.vasquez@qlogic.com&gt;
Signed-off-by: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>pmcraid: reject negative request size</title>
<updated>2011-08-08T17:35:58+00:00</updated>
<author>
<name>Dan Rosenberg</name>
<email>drosenberg@vsecurity.com</email>
</author>
<published>2011-07-11T21:08:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=af5450788196765db7a1a19c6b41524b5a7019d8'/>
<id>af5450788196765db7a1a19c6b41524b5a7019d8</id>
<content type='text'>
commit b5b515445f4f5a905c5dd27e6e682868ccd6c09d upstream.

There's a code path in pmcraid that can be reached via device ioctl that
causes all sorts of ugliness, including heap corruption or triggering the
OOM killer due to consecutive allocation of large numbers of pages.

First, the user can call pmcraid_chr_ioctl(), with a type
PMCRAID_PASSTHROUGH_IOCTL.  This calls through to
pmcraid_ioctl_passthrough().  Next, a pmcraid_passthrough_ioctl_buffer
is copied in, and the request_size variable is set to
buffer-&gt;ioarcb.data_transfer_length, which is an arbitrary 32-bit
signed value provided by the user.  If a negative value is provided
here, bad things can happen.  For example,
pmcraid_build_passthrough_ioadls() is called with this request_size,
which immediately calls pmcraid_alloc_sglist() with a negative size.
The resulting math on allocating a scatter list can result in an
overflow in the kzalloc() call (if num_elem is 0, the sglist will be
smaller than expected), or if num_elem is unexpectedly large the
subsequent loop will call alloc_pages() repeatedly, a high number of
pages will be allocated and the OOM killer might be invoked.

It looks like preventing this value from being negative in
pmcraid_ioctl_passthrough() would be sufficient.

Signed-off-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

There's a code path in pmcraid that can be reached via device ioctl that
causes all sorts of ugliness, including heap corruption or triggering the
OOM killer due to consecutive allocation of large numbers of pages.

First, the user can call pmcraid_chr_ioctl(), with a type
PMCRAID_PASSTHROUGH_IOCTL.  This calls through to
pmcraid_ioctl_passthrough().  Next, a pmcraid_passthrough_ioctl_buffer
is copied in, and the request_size variable is set to
buffer-&gt;ioarcb.data_transfer_length, which is an arbitrary 32-bit
signed value provided by the user.  If a negative value is provided
here, bad things can happen.  For example,
pmcraid_build_passthrough_ioadls() is called with this request_size,
which immediately calls pmcraid_alloc_sglist() with a negative size.
The resulting math on allocating a scatter list can result in an
overflow in the kzalloc() call (if num_elem is 0, the sglist will be
smaller than expected), or if num_elem is unexpectedly large the
subsequent loop will call alloc_pages() repeatedly, a high number of
pages will be allocated and the OOM killer might be invoked.

It looks like preventing this value from being negative in
pmcraid_ioctl_passthrough() would be sufficient.

Signed-off-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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