<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/scsi, branch v3.4.27</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>SCSI: qla2xxx: Test and clear FCPORT_UPDATE_NEEDED atomically.</title>
<updated>2013-01-17T16:50:44+00:00</updated>
<author>
<name>David Jeffery</name>
<email>djeffery@redhat.com</email>
</author>
<published>2012-11-21T07:39:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2e4be18823cb686f1316ac856ce1fbc651dd28e1'/>
<id>2e4be18823cb686f1316ac856ce1fbc651dd28e1</id>
<content type='text'>
commit a394aac88506159e047630fc90dc2242568382d8 upstream.

When the qla2xxx driver loses access to multiple, remote ports, there is a race
condition which can occur which will keep the request stuck on a scsi request
queue indefinitely.

This bad state occurred do to a race condition with how the FCPORT_UPDATE_NEEDED
bit is set in qla2x00_schedule_rport_del(), and how it is cleared in
qla2x00_do_dpc().  The problem port has its drport pointer set, but it has never
been processed by the driver to inform the fc transport that the port has been
lost.  qla2x00_schedule_rport_del() sets drport, and then sets the
FCPORT_UPDATE_NEEDED bit.  In qla2x00_do_dpc(), the port lists are walked and
any drport pointer is handled and the fc transport informed of the port loss,
then the FCPORT_UPDATE_NEEDED bit is cleared.  This leaves a race where the
dpc thread is processing one port removal, another port removal is marked
with a call to qla2x00_schedule_rport_del(), and the dpc thread clears the
bit for both removals, even though only the first removal was actually
handled.  Until another event occurs to set FCPORT_UPDATE_NEEDED, the later
port removal is never finished and qla2xxx stays in a bad state which causes
requests to become stuck on request queues.

This patch updates the driver to test and clear FCPORT_UPDATE_NEEDED
atomically.  This ensures the port state changes are processed and not lost.

Signed-off-by: David Jeffery &lt;djeffery@redhat.com&gt;
Signed-off-by: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Signed-off-by: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 a394aac88506159e047630fc90dc2242568382d8 upstream.

When the qla2xxx driver loses access to multiple, remote ports, there is a race
condition which can occur which will keep the request stuck on a scsi request
queue indefinitely.

This bad state occurred do to a race condition with how the FCPORT_UPDATE_NEEDED
bit is set in qla2x00_schedule_rport_del(), and how it is cleared in
qla2x00_do_dpc().  The problem port has its drport pointer set, but it has never
been processed by the driver to inform the fc transport that the port has been
lost.  qla2x00_schedule_rport_del() sets drport, and then sets the
FCPORT_UPDATE_NEEDED bit.  In qla2x00_do_dpc(), the port lists are walked and
any drport pointer is handled and the fc transport informed of the port loss,
then the FCPORT_UPDATE_NEEDED bit is cleared.  This leaves a race where the
dpc thread is processing one port removal, another port removal is marked
with a call to qla2x00_schedule_rport_del(), and the dpc thread clears the
bit for both removals, even though only the first removal was actually
handled.  Until another event occurs to set FCPORT_UPDATE_NEEDED, the later
port removal is never finished and qla2xxx stays in a bad state which causes
requests to become stuck on request queues.

This patch updates the driver to test and clear FCPORT_UPDATE_NEEDED
atomically.  This ensures the port state changes are processed and not lost.

Signed-off-by: David Jeffery &lt;djeffery@redhat.com&gt;
Signed-off-by: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Signed-off-by: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: prevent stack buffer overflow in host_reset</title>
<updated>2013-01-17T16:50:44+00:00</updated>
<author>
<name>Sasha Levin</name>
<email>sasha.levin@oracle.com</email>
</author>
<published>2012-11-15T20:51:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e21c4b90fb7881357c81a5f68d676747b7dddbb1'/>
<id>e21c4b90fb7881357c81a5f68d676747b7dddbb1</id>
<content type='text'>
commit 072f19b4bea31cdd482d79f805413f2f9ac9e233 upstream.

store_host_reset() has tried to re-invent the wheel to compare sysfs strings.
Unfortunately it did so poorly and never bothered to check the input from
userspace before overwriting stack with it, so something simple as:

echo "WoopsieWoopsie" &gt;
/sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset

would result in:

[  316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7
[  316.310101]
[  316.320051] Pid: 6655, comm: sh Tainted: G        W    3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129
[  316.320051] Call Trace:
[  316.340058] pps pps0: PPS event at 1352918752.620355751
[  316.340062] pps pps0: capture assert seq #303
[  316.320051]  [&lt;ffffffff83b3856b&gt;] panic+0xcd/0x1f4
[  316.320051]  [&lt;ffffffff81f5bac7&gt;] ? store_host_reset+0xd7/0x100
[  316.320051]  [&lt;ffffffff8110b996&gt;] __stack_chk_fail+0x16/0x20
[  316.320051]  [&lt;ffffffff81f5bac7&gt;] store_host_reset+0xd7/0x100
[  316.320051]  [&lt;ffffffff81e55bb3&gt;] dev_attr_store+0x13/0x30
[  316.320051]  [&lt;ffffffff812f7db1&gt;] sysfs_write_file+0x101/0x170
[  316.320051]  [&lt;ffffffff8127acc8&gt;] vfs_write+0xb8/0x180
[  316.320051]  [&lt;ffffffff8127ae80&gt;] sys_write+0x50/0xa0
[  316.320051]  [&lt;ffffffff83c03418&gt;] tracesys+0xe1/0xe6

Fix this by uninventing whatever was going on there and just use sysfs_streq.

Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and
firmware reset").

[jejb: added necessary const to prevent compile warnings]
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 072f19b4bea31cdd482d79f805413f2f9ac9e233 upstream.

store_host_reset() has tried to re-invent the wheel to compare sysfs strings.
Unfortunately it did so poorly and never bothered to check the input from
userspace before overwriting stack with it, so something simple as:

echo "WoopsieWoopsie" &gt;
/sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset

would result in:

[  316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7
[  316.310101]
[  316.320051] Pid: 6655, comm: sh Tainted: G        W    3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129
[  316.320051] Call Trace:
[  316.340058] pps pps0: PPS event at 1352918752.620355751
[  316.340062] pps pps0: capture assert seq #303
[  316.320051]  [&lt;ffffffff83b3856b&gt;] panic+0xcd/0x1f4
[  316.320051]  [&lt;ffffffff81f5bac7&gt;] ? store_host_reset+0xd7/0x100
[  316.320051]  [&lt;ffffffff8110b996&gt;] __stack_chk_fail+0x16/0x20
[  316.320051]  [&lt;ffffffff81f5bac7&gt;] store_host_reset+0xd7/0x100
[  316.320051]  [&lt;ffffffff81e55bb3&gt;] dev_attr_store+0x13/0x30
[  316.320051]  [&lt;ffffffff812f7db1&gt;] sysfs_write_file+0x101/0x170
[  316.320051]  [&lt;ffffffff8127acc8&gt;] vfs_write+0xb8/0x180
[  316.320051]  [&lt;ffffffff8127ae80&gt;] sys_write+0x50/0xa0
[  316.320051]  [&lt;ffffffff83c03418&gt;] tracesys+0xe1/0xe6

Fix this by uninventing whatever was going on there and just use sysfs_streq.

Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and
firmware reset").

[jejb: added necessary const to prevent compile warnings]
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: mvsas: fix undefined bit shift</title>
<updated>2013-01-17T16:50:44+00:00</updated>
<author>
<name>Xi Wang</name>
<email>xi.wang@gmail.com</email>
</author>
<published>2012-11-16T19:40:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3814b31a89b1fbb5c6f92c11c8371a2e4c97d2f1'/>
<id>3814b31a89b1fbb5c6f92c11c8371a2e4c97d2f1</id>
<content type='text'>
commit beecadea1b8d67f591b13f7099559f32f3fd601d upstream.

The macro bit(n) is defined as ((u32)1 &lt;&lt; n), and thus it doesn't work
with n &gt;= 32, such as in mvs_94xx_assign_reg_set():

	if (i &gt;= 32) {
		mvi-&gt;sata_reg_set |= bit(i);
		...
	}

The shift ((u32)1 &lt;&lt; n) with n &gt;= 32 also leads to undefined behavior.
The result varies depending on the architecture.

This patch changes bit(n) to do a 64-bit shift.  It also simplifies
mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined.

Signed-off-by: Xi Wang &lt;xi.wang@gmail.com&gt;
Acked-by: Xiangliang Yu &lt;yuxiangl@marvell.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 beecadea1b8d67f591b13f7099559f32f3fd601d upstream.

The macro bit(n) is defined as ((u32)1 &lt;&lt; n), and thus it doesn't work
with n &gt;= 32, such as in mvs_94xx_assign_reg_set():

	if (i &gt;= 32) {
		mvi-&gt;sata_reg_set |= bit(i);
		...
	}

The shift ((u32)1 &lt;&lt; n) with n &gt;= 32 also leads to undefined behavior.
The result varies depending on the architecture.

This patch changes bit(n) to do a 64-bit shift.  It also simplifies
mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined.

Signed-off-by: Xi Wang &lt;xi.wang@gmail.com&gt;
Acked-by: Xiangliang Yu &lt;yuxiangl@marvell.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: mvsas: Fix oops when ata commond timeout.</title>
<updated>2013-01-17T16:50:43+00:00</updated>
<author>
<name>Jianpeng Ma</name>
<email>majianpeng@gmail.com</email>
</author>
<published>2012-08-04T02:34:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8f735b2774f5e200a65c5fe9143fb431023a5267'/>
<id>8f735b2774f5e200a65c5fe9143fb431023a5267</id>
<content type='text'>
commit 95ab000388974d8ffef8257306b4be6e8778b768 upstream.

Kernel message follows:

[  511.712011] sd 11:0:0:0: [sdf] command ffff8800a4e81400 timed out
[  511.712022] sas: Enter sas_scsi_recover_host busy: 1 failed: 1
[  511.712024] sas: trying to find task 0xffff8800a4d24c80
[  511.712026] sas: sas_scsi_find_task: aborting task 0xffff8800a4d24c80
[  511.712029] drivers/scsi/mvsas/mv_sas.c 1631:mvs_abort_task()
mvi=ffff8800b5300000 task=ffff8800a4d24c80 slot=ffff8800b5325038
slot_idx=x0
[  511.712035] BUG: unable to handle kernel NULL pointer dereference at
0000000000000058
[  511.712040] IP: [&lt;ffffffff815f8c0c&gt;] _raw_spin_lock_irqsave+0xc/0x30
[  511.712047] PGD 0
[  511.712049] Oops: 0002 [#1] SMP
[  511.712052] Modules linked in: mvsas libsas scsi_transport_sas
raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq
async_tx [last unloaded: mvsas]
[  511.712062] CPU 3
[  511.712066] Pid: 7322, comm: scsi_eh_11 Not tainted 3.5.0+ #106 To Be
Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
[  511.712068] RIP: 0010:[&lt;ffffffff815f8c0c&gt;]  [&lt;ffffffff815f8c0c&gt;]
_raw_spin_lock_irqsave+0xc/0x30
[  511.712073] RSP: 0018:ffff880098d3bcb0  EFLAGS: 00010086
[  511.712074] RAX: 0000000000000286 RBX: 0000000000000058 RCX:
00000000000000c3
[  511.712076] RDX: 0000000000000100 RSI: 0000000000000046 RDI:
0000000000000058
[  511.712078] RBP: ffff880098d3bcb0 R08: 000000000000000a R09:
0000000000000000
[  511.712080] R10: 00000000000004e8 R11: 00000000000004e7 R12:
ffff8800a4d24c80
[  511.712082] R13: 0000000000000050 R14: ffff8800b5325038 R15:
ffff8800a4eafe00
[  511.712084] FS:  0000000000000000(0000) GS:ffff8800bdb80000(0000)
knlGS:0000000000000000
[  511.712086] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  511.712088] CR2: 0000000000000058 CR3: 00000000a4ce6000 CR4:
00000000000407e0
[  511.712090] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[  511.712091] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[  511.712093] Process scsi_eh_11 (pid: 7322, threadinfo
ffff880098d3a000, task ffff8800a61dde40)
[  511.712095] Stack:
[  511.712096]  ffff880098d3bce0 ffffffff81060683 ffff880000000000
0000000000000000
[  511.712099]  ffff8800a4d24c80 ffff8800b5300000 ffff880098d3bcf0
ffffffffa0076a88
[  511.712102]  ffff880098d3bd50 ffffffffa0079bb5 ffff880000000000
ffff880000000018
[  511.712106] Call Trace:
[  511.712110]  [&lt;ffffffff81060683&gt;] complete+0x23/0x60
[  511.712115]  [&lt;ffffffffa0076a88&gt;] mvs_tmf_timedout+0x18/0x20 [mvsas]
[  511.712119]  [&lt;ffffffffa0079bb5&gt;] mvs_slot_complete+0x765/0x7d0
[mvsas]
[  511.712125]  [&lt;ffffffffa005a17d&gt;] sas_scsi_recover_host+0x55d/0xdb0
[libsas]
[  511.712128]  [&lt;ffffffff8106d600&gt;] ? idle_balance+0xe0/0x130
[  511.712133]  [&lt;ffffffff813b150c&gt;] scsi_error_handler+0xcc/0x470
[  511.712136]  [&lt;ffffffff815f7ad0&gt;] ? __schedule+0x370/0x730
[  511.712139]  [&lt;ffffffff8105f728&gt;] ? __wake_up_common+0x58/0x90
[  511.712142]  [&lt;ffffffff813b1440&gt;] ? scsi_eh_get_sense+0x110/0x110
[  511.712146]  [&lt;ffffffff810571be&gt;] kthread+0x8e/0xa0
[  511.712150]  [&lt;ffffffff816015f4&gt;] kernel_thread_helper+0x4/0x10
[  511.712153]  [&lt;ffffffff81057130&gt;] ? flush_kthread_work+0x120/0x120
[  511.712156]  [&lt;ffffffff816015f0&gt;] ? gs_change+0xb/0xb
[  511.712157] Code: 8a 00 01 00 00 89 d0 f0 66 0f b1 0f 66 39 d0 0f 94
c0 0f b6 c0 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 9c 58 fa ba 00 01
00 00 &lt;f0&gt; 66 0f c1 17 0f b6 ce 38 d1 74 11 0f 1f 84 00 00 00 00 00 f3
[  511.712191] RIP  [&lt;ffffffff815f8c0c&gt;] _raw_spin_lock_irqsave+0xc/0x30
[  511.712194]  RSP &lt;ffff880098d3bcb0&gt;
[  511.712196] CR2: 0000000000000058
[  511.712198] ---[ end trace a781c7b1e65db92c ]---

Signed-off-by: Jianpeng Ma &lt;majianpeng@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Cc: CAI Qian &lt;caiqian@redhat.com&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 95ab000388974d8ffef8257306b4be6e8778b768 upstream.

Kernel message follows:

[  511.712011] sd 11:0:0:0: [sdf] command ffff8800a4e81400 timed out
[  511.712022] sas: Enter sas_scsi_recover_host busy: 1 failed: 1
[  511.712024] sas: trying to find task 0xffff8800a4d24c80
[  511.712026] sas: sas_scsi_find_task: aborting task 0xffff8800a4d24c80
[  511.712029] drivers/scsi/mvsas/mv_sas.c 1631:mvs_abort_task()
mvi=ffff8800b5300000 task=ffff8800a4d24c80 slot=ffff8800b5325038
slot_idx=x0
[  511.712035] BUG: unable to handle kernel NULL pointer dereference at
0000000000000058
[  511.712040] IP: [&lt;ffffffff815f8c0c&gt;] _raw_spin_lock_irqsave+0xc/0x30
[  511.712047] PGD 0
[  511.712049] Oops: 0002 [#1] SMP
[  511.712052] Modules linked in: mvsas libsas scsi_transport_sas
raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq
async_tx [last unloaded: mvsas]
[  511.712062] CPU 3
[  511.712066] Pid: 7322, comm: scsi_eh_11 Not tainted 3.5.0+ #106 To Be
Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
[  511.712068] RIP: 0010:[&lt;ffffffff815f8c0c&gt;]  [&lt;ffffffff815f8c0c&gt;]
_raw_spin_lock_irqsave+0xc/0x30
[  511.712073] RSP: 0018:ffff880098d3bcb0  EFLAGS: 00010086
[  511.712074] RAX: 0000000000000286 RBX: 0000000000000058 RCX:
00000000000000c3
[  511.712076] RDX: 0000000000000100 RSI: 0000000000000046 RDI:
0000000000000058
[  511.712078] RBP: ffff880098d3bcb0 R08: 000000000000000a R09:
0000000000000000
[  511.712080] R10: 00000000000004e8 R11: 00000000000004e7 R12:
ffff8800a4d24c80
[  511.712082] R13: 0000000000000050 R14: ffff8800b5325038 R15:
ffff8800a4eafe00
[  511.712084] FS:  0000000000000000(0000) GS:ffff8800bdb80000(0000)
knlGS:0000000000000000
[  511.712086] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  511.712088] CR2: 0000000000000058 CR3: 00000000a4ce6000 CR4:
00000000000407e0
[  511.712090] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[  511.712091] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[  511.712093] Process scsi_eh_11 (pid: 7322, threadinfo
ffff880098d3a000, task ffff8800a61dde40)
[  511.712095] Stack:
[  511.712096]  ffff880098d3bce0 ffffffff81060683 ffff880000000000
0000000000000000
[  511.712099]  ffff8800a4d24c80 ffff8800b5300000 ffff880098d3bcf0
ffffffffa0076a88
[  511.712102]  ffff880098d3bd50 ffffffffa0079bb5 ffff880000000000
ffff880000000018
[  511.712106] Call Trace:
[  511.712110]  [&lt;ffffffff81060683&gt;] complete+0x23/0x60
[  511.712115]  [&lt;ffffffffa0076a88&gt;] mvs_tmf_timedout+0x18/0x20 [mvsas]
[  511.712119]  [&lt;ffffffffa0079bb5&gt;] mvs_slot_complete+0x765/0x7d0
[mvsas]
[  511.712125]  [&lt;ffffffffa005a17d&gt;] sas_scsi_recover_host+0x55d/0xdb0
[libsas]
[  511.712128]  [&lt;ffffffff8106d600&gt;] ? idle_balance+0xe0/0x130
[  511.712133]  [&lt;ffffffff813b150c&gt;] scsi_error_handler+0xcc/0x470
[  511.712136]  [&lt;ffffffff815f7ad0&gt;] ? __schedule+0x370/0x730
[  511.712139]  [&lt;ffffffff8105f728&gt;] ? __wake_up_common+0x58/0x90
[  511.712142]  [&lt;ffffffff813b1440&gt;] ? scsi_eh_get_sense+0x110/0x110
[  511.712146]  [&lt;ffffffff810571be&gt;] kthread+0x8e/0xa0
[  511.712150]  [&lt;ffffffff816015f4&gt;] kernel_thread_helper+0x4/0x10
[  511.712153]  [&lt;ffffffff81057130&gt;] ? flush_kthread_work+0x120/0x120
[  511.712156]  [&lt;ffffffff816015f0&gt;] ? gs_change+0xb/0xb
[  511.712157] Code: 8a 00 01 00 00 89 d0 f0 66 0f b1 0f 66 39 d0 0f 94
c0 0f b6 c0 5d c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 9c 58 fa ba 00 01
00 00 &lt;f0&gt; 66 0f c1 17 0f b6 ce 38 d1 74 11 0f 1f 84 00 00 00 00 00 f3
[  511.712191] RIP  [&lt;ffffffff815f8c0c&gt;] _raw_spin_lock_irqsave+0xc/0x30
[  511.712194]  RSP &lt;ffff880098d3bcb0&gt;
[  511.712196] CR2: 0000000000000058
[  511.712198] ---[ end trace a781c7b1e65db92c ]---

Signed-off-by: Jianpeng Ma &lt;majianpeng@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Cc: CAI Qian &lt;caiqian@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: isci: copy fis 0x34 response into proper buffer</title>
<updated>2012-12-03T19:46:49+00:00</updated>
<author>
<name>Maciej Patelczyk</name>
<email>maciej.patelczyk@intel.com</email>
</author>
<published>2012-10-15T12:29:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6417635908e7643800141fc1d6cf7fe43f4fb5e3'/>
<id>6417635908e7643800141fc1d6cf7fe43f4fb5e3</id>
<content type='text'>
commit 49bd665c5407a453736d3232ee58f2906b42e83c upstream.

SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register
Device to Host (FIS 0x34) frame Initiator resets phy.
In the frame handler routine response (FIS 0x34) was copied into wrong
buffer and upper layer did not receive any answer which resulted in
timeout and reset.
This patch corrects this bug.

Signed-off-by: Maciej Patelczyk &lt;maciej.patelczyk@intel.com&gt;
Signed-off-by: Lukasz Dorau &lt;lukasz.dorau@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 49bd665c5407a453736d3232ee58f2906b42e83c upstream.

SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register
Device to Host (FIS 0x34) frame Initiator resets phy.
In the frame handler routine response (FIS 0x34) was copied into wrong
buffer and upper layer did not receive any answer which resulted in
timeout and reset.
This patch corrects this bug.

Signed-off-by: Maciej Patelczyk &lt;maciej.patelczyk@intel.com&gt;
Signed-off-by: Lukasz Dorau &lt;lukasz.dorau@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: aha152x: Fix sparse warning and make printing pointer address more portable.</title>
<updated>2012-12-03T19:46:37+00:00</updated>
<author>
<name>Krzysztof Wilczynski</name>
<email>krzysztof.wilczynski@linux.com</email>
</author>
<published>2012-05-02T10:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6df5eea2553e9b66c2ef1f68dfd4b8867e2ff740'/>
<id>6df5eea2553e9b66c2ef1f68dfd4b8867e2ff740</id>
<content type='text'>
commit b631cf1f899f9d2e449884dbccc34940637c639f upstream.

This is to change use of "0x%08x" in favour of "%p" as per ../Documentation/printk-formats.txt,
which also takes care about the following warning during compilation time:

  drivers/scsi/aha152x.c: In function ‘get_command’:
  drivers/scsi/aha152x.c:2987: warning: cast from pointer to integer of different size

Signed-off-by: Krzysztof Wilczynski &lt;krzysztof.wilczynski@linux.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&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 b631cf1f899f9d2e449884dbccc34940637c639f upstream.

This is to change use of "0x%08x" in favour of "%p" as per ../Documentation/printk-formats.txt,
which also takes care about the following warning during compilation time:

  drivers/scsi/aha152x.c: In function ‘get_command’:
  drivers/scsi/aha152x.c:2987: warning: cast from pointer to integer of different size

Signed-off-by: Krzysztof Wilczynski &lt;krzysztof.wilczynski@linux.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mvsas: remove unused variable in mvs_task_exec()</title>
<updated>2012-12-03T19:46:37+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2012-06-22T06:36:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cbe6d9bd065c64cb9eac67d9a12001e095f875b9'/>
<id>cbe6d9bd065c64cb9eac67d9a12001e095f875b9</id>
<content type='text'>
commit cca85013ef54f66eb4616e6f3860549a96c8338b upstream.

We don't use "dev" any more after 07ec747a5f ("libsas: remove
ata_port.lock management duties from lldds") and it causes a compile
warning.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: Xiangliang Yu &lt;yuxiangl@marvell.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 cca85013ef54f66eb4616e6f3860549a96c8338b upstream.

We don't use "dev" any more after 07ec747a5f ("libsas: remove
ata_port.lock management duties from lldds") and it causes a compile
warning.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: Xiangliang Yu &lt;yuxiangl@marvell.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: scsi_debug: Fix off-by-one bug when unmapping region</title>
<updated>2012-10-21T16:27:58+00:00</updated>
<author>
<name>Lukas Czerner</name>
<email>lczerner@redhat.com</email>
</author>
<published>2012-08-16T14:38:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=023f18fee60cd9ef86c8299dd9debccad1f93351'/>
<id>023f18fee60cd9ef86c8299dd9debccad1f93351</id>
<content type='text'>
commit bc977749e967daa56de1922cf4cb38525631c51c upstream.

Currently it is possible to unmap one more block than user requested to
due to the off-by-one error in unmap_region(). This is probably due to
the fact that the end variable despite its name actually points to the
last block to unmap + 1. However in the condition it is handled as the
last block of the region to unmap.

The bug was not previously spotted probably due to the fact that the
region was not zeroed, which has changed with commit
be1dd78de5686c062bb3103f9e86d444a10ed783. With that commit we were able
to corrupt the ext4 file system on 256M scsi_debug device with LBPRZ
enabled using fstrim.

Since the 'end' semantic is the same in several functions there this
commit just fixes the condition to use the 'end' variable correctly in
that context.

Reported-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Lukas Czerner &lt;lczerner@redhat.com&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Acked-by: Douglas Gilbert &lt;dgilbert@interlog.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 bc977749e967daa56de1922cf4cb38525631c51c upstream.

Currently it is possible to unmap one more block than user requested to
due to the off-by-one error in unmap_region(). This is probably due to
the fact that the end variable despite its name actually points to the
last block to unmap + 1. However in the condition it is handled as the
last block of the region to unmap.

The bug was not previously spotted probably due to the fact that the
region was not zeroed, which has changed with commit
be1dd78de5686c062bb3103f9e86d444a10ed783. With that commit we were able
to corrupt the ext4 file system on 256M scsi_debug device with LBPRZ
enabled using fstrim.

Since the 'end' semantic is the same in several functions there this
commit just fixes the condition to use the 'end' variable correctly in
that context.

Reported-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Lukas Czerner &lt;lczerner@redhat.com&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Acked-by: Douglas Gilbert &lt;dgilbert@interlog.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: storvsc: Account for in-transit packets in the RESET path</title>
<updated>2012-10-21T16:27:58+00:00</updated>
<author>
<name>K. Y. Srinivasan</name>
<email>kys@microsoft.com</email>
</author>
<published>2012-10-02T18:03:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=791f153c5bea0636537ceb417bfea78f0f232d4f'/>
<id>791f153c5bea0636537ceb417bfea78f0f232d4f</id>
<content type='text'>
commit 5c1b10ab7f93d24f29b5630286e323d1c5802d5c upstream.

Properly account for I/O in transit before returning from the RESET call.
In the absense of this patch, we could have a situation where the host may
respond to a command that was issued prior to the issuance of the RESET
command at some arbitrary time after responding to the RESET command.
Currently, the host does not do anything with the RESET command.

Signed-off-by: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 5c1b10ab7f93d24f29b5630286e323d1c5802d5c upstream.

Properly account for I/O in transit before returning from the RESET call.
In the absense of this patch, we could have a situation where the host may
respond to a command that was issued prior to the issuance of the RESET
command at some arbitrary time after responding to the RESET command.
Currently, the host does not do anything with the RESET command.

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

</pre>
</div>
</content>
</entry>
<entry>
<title>SCSI: hpsa: dial down lockup detection during firmware flash</title>
<updated>2012-10-21T16:27:58+00:00</updated>
<author>
<name>Stephen M. Cameron</name>
<email>scameron@beardog.cce.hp.com</email>
</author>
<published>2012-05-01T16:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8892290fcc4476db20bbe591d9c0d401096d6275'/>
<id>8892290fcc4476db20bbe591d9c0d401096d6275</id>
<content type='text'>
commit e85c59746957fd6e3595d02cf614370056b5816e upstream.

Dial back the aggressiveness of the controller lockup detection thread.
Currently it will declare the controller to be locked up if it goes
for 10 seconds with no interrupts and no change in the heartbeat
register.  Dial back this to 30 seconds with no heartbeat change, and
also snoop the ioctl path and if a firmware flash command is detected,
dial it back further to 4 minutes until the firmware flash command
completes.  The reason for this is that during the firmware flash
operation, the controller apparently doesn't update the heartbeat
register as frequently as it is supposed to, and we can get a false
positive.

Signed-off-by: Stephen M. Cameron &lt;scameron@beardog.cce.hp.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&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 e85c59746957fd6e3595d02cf614370056b5816e upstream.

Dial back the aggressiveness of the controller lockup detection thread.
Currently it will declare the controller to be locked up if it goes
for 10 seconds with no interrupts and no change in the heartbeat
register.  Dial back this to 30 seconds with no heartbeat change, and
also snoop the ioctl path and if a firmware flash command is detected,
dial it back further to 4 minutes until the firmware flash command
completes.  The reason for this is that during the firmware flash
operation, the controller apparently doesn't update the heartbeat
register as frequently as it is supposed to, and we can get a false
positive.

Signed-off-by: Stephen M. Cameron &lt;scameron@beardog.cce.hp.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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