<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/scsi, branch v3.16.78</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()</title>
<updated>2019-10-05T15:20:03+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2019-06-19T07:05:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a7b6e4f04e9d912d5b2a1785d00a327f7bc985d4'/>
<id>a7b6e4f04e9d912d5b2a1785d00a327f7bc985d4</id>
<content type='text'>
commit 240b4cc8fd5db138b675297d4226ec46594d9b3b upstream.

Once we unlock adapter-&gt;hw_lock in pvscsi_queue_lck() nothing prevents just
queued scsi_cmnd from completing and freeing the request. Thus cmd-&gt;cmnd[0]
dereference can dereference already freed request leading to kernel crashes
or other issues (which one of our customers observed). Store cmd-&gt;cmnd[0]
in a local variable before unlocking adapter-&gt;hw_lock to fix the issue.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 240b4cc8fd5db138b675297d4226ec46594d9b3b upstream.

Once we unlock adapter-&gt;hw_lock in pvscsi_queue_lck() nothing prevents just
queued scsi_cmnd from completing and freeing the request. Thus cmd-&gt;cmnd[0]
dereference can dereference already freed request leading to kernel crashes
or other issues (which one of our customers observed). Store cmd-&gt;cmnd[0]
in a local variable before unlocking adapter-&gt;hw_lock to fix the issue.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: ufs: Avoid runtime suspend possibly being blocked forever</title>
<updated>2019-10-05T15:20:02+00:00</updated>
<author>
<name>Stanley Chu</name>
<email>stanley.chu@mediatek.com</email>
</author>
<published>2019-06-12T15:19:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b71e15e286dd18aaaaf76d3474e61bc71c03c2ce'/>
<id>b71e15e286dd18aaaaf76d3474e61bc71c03c2ce</id>
<content type='text'>
commit 24e2e7a19f7e4b83d0d5189040d997bce3596473 upstream.

UFS runtime suspend can be triggered after pm_runtime_enable() is invoked
in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered
before binding ufs_hba structure to ufs device structure via
platform_set_drvdata(), then UFS runtime suspend will be no longer
triggered in the future because its dev-&gt;power.runtime_error was set in the
first triggering and does not have any chance to be cleared.

To be more clear, dev-&gt;power.runtime_error is set if hba is NULL in
ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where
dev-&gt;power.runtime_error is set as -EINVAL. In this case, any future
rpm_suspend() for UFS device fails because rpm_check_suspend_allowed()
fails due to non-zero
dev-&gt;power.runtime_error.

To resolve this issue, make sure the first UFS runtime suspend get valid
"hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is
successfully bound to UFS device structure.

Fixes: 62694735ca95 ([SCSI] ufs: Add runtime PM support for UFS host controller driver)
Signed-off-by: Stanley Chu &lt;stanley.chu@mediatek.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
[bwh: Backported to 3.16:
 - ufshcd_pltrfm_probe() doesn't allocate or free the host structure
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 24e2e7a19f7e4b83d0d5189040d997bce3596473 upstream.

UFS runtime suspend can be triggered after pm_runtime_enable() is invoked
in ufshcd_pltfrm_init(). However if the first runtime suspend is triggered
before binding ufs_hba structure to ufs device structure via
platform_set_drvdata(), then UFS runtime suspend will be no longer
triggered in the future because its dev-&gt;power.runtime_error was set in the
first triggering and does not have any chance to be cleared.

To be more clear, dev-&gt;power.runtime_error is set if hba is NULL in
ufshcd_runtime_suspend() which returns -EINVAL to rpm_callback() where
dev-&gt;power.runtime_error is set as -EINVAL. In this case, any future
rpm_suspend() for UFS device fails because rpm_check_suspend_allowed()
fails due to non-zero
dev-&gt;power.runtime_error.

To resolve this issue, make sure the first UFS runtime suspend get valid
"hba" in ufshcd_runtime_suspend(): Enable UFS runtime PM only after hba is
successfully bound to UFS device structure.

Fixes: 62694735ca95 ([SCSI] ufs: Add runtime PM support for UFS host controller driver)
Signed-off-by: Stanley Chu &lt;stanley.chu@mediatek.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
[bwh: Backported to 3.16:
 - ufshcd_pltrfm_probe() doesn't allocate or free the host structure
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: bnx2fc: fix incorrect cast to u64 on shift operation</title>
<updated>2019-10-05T15:19:37+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2019-05-04T16:48:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1462cd0da1668beaa1cc4162742c6f6732ed42d8'/>
<id>1462cd0da1668beaa1cc4162742c6f6732ed42d8</id>
<content type='text'>
commit d0c0d902339249c75da85fd9257a86cbb98dfaa5 upstream.

Currently an int is being shifted and the result is being cast to a u64
which leads to undefined behaviour if the shift is more than 31 bits. Fix
this by casting the integer value 1 to u64 before the shift operation.

Addresses-Coverity: ("Bad shift operation")
Fixes: 7b594769120b ("[SCSI] bnx2fc: Handle REC_TOV error code from firmware")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Acked-by: Saurav Kashyap &lt;skashyap@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d0c0d902339249c75da85fd9257a86cbb98dfaa5 upstream.

Currently an int is being shifted and the result is being cast to a u64
which leads to undefined behaviour if the shift is more than 31 bits. Fix
this by casting the integer value 1 to u64 before the shift operation.

Addresses-Coverity: ("Bad shift operation")
Fixes: 7b594769120b ("[SCSI] bnx2fc: Handle REC_TOV error code from firmware")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Acked-by: Saurav Kashyap &lt;skashyap@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: libsas: delete sas port if expander discover failed</title>
<updated>2019-09-23T20:12:16+00:00</updated>
<author>
<name>Jason Yan</name>
<email>yanaijie@huawei.com</email>
</author>
<published>2019-05-14T02:42:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=03e6d05e78d421221bca0f7480c59e1c202c54e9'/>
<id>03e6d05e78d421221bca0f7480c59e1c202c54e9</id>
<content type='text'>
commit 3b0541791453fbe7f42867e310e0c9eb6295364d upstream.

The sas_port(phy-&gt;port) allocated in sas_ex_discover_expander() will not be
deleted when the expander failed to discover. This will cause resource leak
and a further issue of kernel BUG like below:

[159785.843156]  port-2:17:29: trying to add phy phy-2:17:29 fails: it's
already part of another port
[159785.852144] ------------[ cut here  ]------------
[159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086!
[159785.863000] Internal error: Oops - BUG: 0 [#1] SMP
[159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G
W  OE     4.19.25-vhulk1901.1.0.h111.aarch64 #1
[159785.878458] Hardware name: Huawei Technologies Co., Ltd.
Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019
[159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain
[159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO)
[159785.900094] pc : sas_port_add_phy+0x188/0x1b8
[159785.904524] lr : sas_port_add_phy+0x188/0x1b8
[159785.908952] sp : ffff0001120e3b80
[159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000
[159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560
[159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000
[159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708
[159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400
[159785.939264] x19: ffff802adea2d800 x18: 0000000000000010
[159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0
[159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165
[159785.955417] x13: 726c612073277469 x12: ffff00006887b830
[159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020
[159785.966186] x9 : 0000000000002453 x8 : 726f702072656874
[159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290
[159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000
[159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00
[159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000
[159785.993108] Process kworker/u96:2 (pid: 16993, stack limit =
0x0000000072dae094)
[159786.000576] Call trace:
[159786.003097]  sas_port_add_phy+0x188/0x1b8
[159786.007179]  sas_ex_get_linkrate.isra.5+0x134/0x140
[159786.012130]  sas_ex_discover_expander+0x128/0x408
[159786.016906]  sas_ex_discover_dev+0x218/0x4c8
[159786.021249]  sas_ex_discover_devices+0x9c/0x1a8
[159786.025852]  sas_discover_root_expander+0x134/0x160
[159786.030802]  sas_discover_domain+0x1b8/0x1e8
[159786.035148]  process_one_work+0x1b4/0x3f8
[159786.039230]  worker_thread+0x54/0x470
[159786.042967]  kthread+0x134/0x138
[159786.046269]  ret_from_fork+0x10/0x18
[159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000)
[159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE)
hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE)
[159786.067202] ---[ end trace 03622b9e2d99e196  ]---
[159786.071893] Kernel panic - not syncing: Fatal exception
[159786.077190] SMP: stopping secondary CPUs
[159786.081192] Kernel Offset: disabled
[159786.084753] CPU features: 0x2,a2a00a38

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Reported-by: Jian Luo &lt;luojian5@huawei.com&gt;
Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
CC: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3b0541791453fbe7f42867e310e0c9eb6295364d upstream.

The sas_port(phy-&gt;port) allocated in sas_ex_discover_expander() will not be
deleted when the expander failed to discover. This will cause resource leak
and a further issue of kernel BUG like below:

[159785.843156]  port-2:17:29: trying to add phy phy-2:17:29 fails: it's
already part of another port
[159785.852144] ------------[ cut here  ]------------
[159785.856833] kernel BUG at drivers/scsi/scsi_transport_sas.c:1086!
[159785.863000] Internal error: Oops - BUG: 0 [#1] SMP
[159785.867866] CPU: 39 PID: 16993 Comm: kworker/u96:2 Tainted: G
W  OE     4.19.25-vhulk1901.1.0.h111.aarch64 #1
[159785.878458] Hardware name: Huawei Technologies Co., Ltd.
Hi1620EVBCS/Hi1620EVBCS, BIOS Hi1620 CS B070 1P TA 03/21/2019
[159785.889231] Workqueue: 0000:74:02.0_disco_q sas_discover_domain
[159785.895224] pstate: 40c00009 (nZcv daif +PAN +UAO)
[159785.900094] pc : sas_port_add_phy+0x188/0x1b8
[159785.904524] lr : sas_port_add_phy+0x188/0x1b8
[159785.908952] sp : ffff0001120e3b80
[159785.912341] x29: ffff0001120e3b80 x28: 0000000000000000
[159785.917727] x27: ffff802ade8f5400 x26: ffff0000681b7560
[159785.923111] x25: ffff802adf11a800 x24: ffff0000680e8000
[159785.928496] x23: ffff802ade8f5728 x22: ffff802ade8f5708
[159785.933880] x21: ffff802adea2db40 x20: ffff802ade8f5400
[159785.939264] x19: ffff802adea2d800 x18: 0000000000000010
[159785.944649] x17: 00000000821bf734 x16: ffff00006714faa0
[159785.950033] x15: ffff0000e8ab4ecf x14: 7261702079646165
[159785.955417] x13: 726c612073277469 x12: ffff00006887b830
[159785.960802] x11: ffff00006773eaa0 x10: 7968702079687020
[159785.966186] x9 : 0000000000002453 x8 : 726f702072656874
[159785.971570] x7 : 6f6e6120666f2074 x6 : ffff802bcfb21290
[159785.976955] x5 : ffff802bcfb21290 x4 : 0000000000000000
[159785.982339] x3 : ffff802bcfb298c8 x2 : 337752b234c2ab00
[159785.987723] x1 : 337752b234c2ab00 x0 : 0000000000000000
[159785.993108] Process kworker/u96:2 (pid: 16993, stack limit =
0x0000000072dae094)
[159786.000576] Call trace:
[159786.003097]  sas_port_add_phy+0x188/0x1b8
[159786.007179]  sas_ex_get_linkrate.isra.5+0x134/0x140
[159786.012130]  sas_ex_discover_expander+0x128/0x408
[159786.016906]  sas_ex_discover_dev+0x218/0x4c8
[159786.021249]  sas_ex_discover_devices+0x9c/0x1a8
[159786.025852]  sas_discover_root_expander+0x134/0x160
[159786.030802]  sas_discover_domain+0x1b8/0x1e8
[159786.035148]  process_one_work+0x1b4/0x3f8
[159786.039230]  worker_thread+0x54/0x470
[159786.042967]  kthread+0x134/0x138
[159786.046269]  ret_from_fork+0x10/0x18
[159786.049918] Code: 91322300 f0004402 91178042 97fe4c9b (d4210000)
[159786.056083] Modules linked in: hns3_enet_ut(OE) hclge(OE) hnae3(OE)
hisi_sas_test_hw(OE) hisi_sas_test_main(OE) serdes(OE)
[159786.067202] ---[ end trace 03622b9e2d99e196  ]---
[159786.071893] Kernel panic - not syncing: Fatal exception
[159786.077190] SMP: stopping secondary CPUs
[159786.081192] Kernel Offset: disabled
[159786.084753] CPU features: 0x2,a2a00a38

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Reported-by: Jian Luo &lt;luojian5@huawei.com&gt;
Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
CC: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: qla2xxx: Unregister chrdev if module initialization fails</title>
<updated>2019-09-23T20:11:40+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2019-04-04T19:44:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d074bff84ed8dff76be32a1d2a4a4c2e48ec291b'/>
<id>d074bff84ed8dff76be32a1d2a4a4c2e48ec291b</id>
<content type='text'>
commit c794d24ec9eb6658909955772e70f34bef5b5b91 upstream.

If module initialization fails after the character device has been
registered, unregister the character device. Additionally, avoid
duplicating error path code.

Cc: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Cc: Giridhar Malavali &lt;giridhar.malavali@qlogic.com&gt;
Fixes: 6a03b4cd78f3 ("[SCSI] qla2xxx: Add char device to increase driver use count") # v2.6.35.
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c794d24ec9eb6658909955772e70f34bef5b5b91 upstream.

If module initialization fails after the character device has been
registered, unregister the character device. Additionally, avoid
duplicating error path code.

Cc: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Cc: Giridhar Malavali &lt;giridhar.malavali@qlogic.com&gt;
Fixes: 6a03b4cd78f3 ("[SCSI] qla2xxx: Add char device to increase driver use count") # v2.6.35.
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: qla2xxx: Fix incorrect region-size setting in optrom SYSFS routines</title>
<updated>2019-09-23T20:11:37+00:00</updated>
<author>
<name>Andrew Vasquez</name>
<email>andrewv@marvell.com</email>
</author>
<published>2019-04-02T21:24:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0166dc4aae7eb4c2faf709a989260214edc9b388'/>
<id>0166dc4aae7eb4c2faf709a989260214edc9b388</id>
<content type='text'>
commit 5cbdae10bf11f96e30b4d14de7b08c8b490e903c upstream.

Commit e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs
code") incorrectly set 'optrom_region_size' to 'start+size', which can
overflow option-rom boundaries when 'start' is non-zero.  Continue setting
optrom_region_size to the proper adjusted value of 'size'.

Fixes: e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs code")
Signed-off-by: Andrew Vasquez &lt;andrewv@marvell.com&gt;
Signed-off-by: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5cbdae10bf11f96e30b4d14de7b08c8b490e903c upstream.

Commit e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs
code") incorrectly set 'optrom_region_size' to 'start+size', which can
overflow option-rom boundaries when 'start' is non-zero.  Continue setting
optrom_region_size to the proper adjusted value of 'size'.

Fixes: e6f77540c067 ("scsi: qla2xxx: Fix an integer overflow in sysfs code")
Signed-off-by: Andrew Vasquez &lt;andrewv@marvell.com&gt;
Signed-off-by: Himanshu Madhani &lt;hmadhani@marvell.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: qla4xxx: avoid freeing unallocated dma memory</title>
<updated>2019-09-23T20:11:34+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2019-03-22T14:25:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=628e3360335edae69ef52484439bc7a1e985415d'/>
<id>628e3360335edae69ef52484439bc7a1e985415d</id>
<content type='text'>
commit 608f729c31d4caf52216ea00d20092a80959256d upstream.

Clang -Wuninitialized notices that on is_qla40XX we never allocate any DMA
memory in get_fw_boot_info() but attempt to free it anyway:

drivers/scsi/qla4xxx/ql4_os.c:5915:7: error: variable 'buf_dma' is used uninitialized whenever 'if' condition is false
      [-Werror,-Wsometimes-uninitialized]
                if (!(val &amp; 0x07)) {
                    ^~~~~~~~~~~~~
drivers/scsi/qla4xxx/ql4_os.c:5985:47: note: uninitialized use occurs here
        dma_free_coherent(&amp;ha-&gt;pdev-&gt;dev, size, buf, buf_dma);
                                                     ^~~~~~~
drivers/scsi/qla4xxx/ql4_os.c:5915:3: note: remove the 'if' if its condition is always true
                if (!(val &amp; 0x07)) {
                ^~~~~~~~~~~~~~~~~~~
drivers/scsi/qla4xxx/ql4_os.c:5885:20: note: initialize the variable 'buf_dma' to silence this warning
        dma_addr_t buf_dma;
                          ^
                           = 0

Skip the call to dma_free_coherent() here.

Fixes: 2a991c215978 ("[SCSI] qla4xxx: Boot from SAN support for open-iscsi")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 608f729c31d4caf52216ea00d20092a80959256d upstream.

Clang -Wuninitialized notices that on is_qla40XX we never allocate any DMA
memory in get_fw_boot_info() but attempt to free it anyway:

drivers/scsi/qla4xxx/ql4_os.c:5915:7: error: variable 'buf_dma' is used uninitialized whenever 'if' condition is false
      [-Werror,-Wsometimes-uninitialized]
                if (!(val &amp; 0x07)) {
                    ^~~~~~~~~~~~~
drivers/scsi/qla4xxx/ql4_os.c:5985:47: note: uninitialized use occurs here
        dma_free_coherent(&amp;ha-&gt;pdev-&gt;dev, size, buf, buf_dma);
                                                     ^~~~~~~
drivers/scsi/qla4xxx/ql4_os.c:5915:3: note: remove the 'if' if its condition is always true
                if (!(val &amp; 0x07)) {
                ^~~~~~~~~~~~~~~~~~~
drivers/scsi/qla4xxx/ql4_os.c:5885:20: note: initialize the variable 'buf_dma' to silence this warning
        dma_addr_t buf_dma;
                          ^
                           = 0

Skip the call to dma_free_coherent() here.

Fixes: 2a991c215978 ("[SCSI] qla4xxx: Boot from SAN support for open-iscsi")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: libsas: fix a race condition when smp task timeout</title>
<updated>2019-08-13T11:39:33+00:00</updated>
<author>
<name>Jason Yan</name>
<email>yanaijie@huawei.com</email>
</author>
<published>2018-09-25T02:56:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d5534b2998f7c7009e600d57f27f68ed45779da2'/>
<id>d5534b2998f7c7009e600d57f27f68ed45779da2</id>
<content type='text'>
commit b90cd6f2b905905fb42671009dc0e27c310a16ae upstream.

When the lldd is processing the complete sas task in interrupt and set the
task stat as SAS_TASK_STATE_DONE, the smp timeout timer is able to be
triggered at the same time. And smp_task_timedout() will complete the task
wheter the SAS_TASK_STATE_DONE is set or not. Then the sas task may freed
before lldd end the interrupt process. Thus a use-after-free will happen.

Fix this by calling the complete() only when SAS_TASK_STATE_DONE is not
set. And remove the check of the return value of the del_timer(). Once the
LLDD sets DONE, it must call task-&gt;done(), which will call
smp_task_done()-&gt;complete() and the task will be completed and freed
correctly.

Reported-by: chenxiang &lt;chenxiang66@hisilicon.com&gt;
Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
CC: John Garry &lt;john.garry@huawei.com&gt;
CC: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
CC: Ewan Milne &lt;emilne@redhat.com&gt;
CC: Christoph Hellwig &lt;hch@lst.de&gt;
CC: Tomas Henzl &lt;thenzl@redhat.com&gt;
CC: Dan Williams &lt;dan.j.williams@intel.com&gt;
CC: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: John Garry &lt;john.garry@huawei.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b90cd6f2b905905fb42671009dc0e27c310a16ae upstream.

When the lldd is processing the complete sas task in interrupt and set the
task stat as SAS_TASK_STATE_DONE, the smp timeout timer is able to be
triggered at the same time. And smp_task_timedout() will complete the task
wheter the SAS_TASK_STATE_DONE is set or not. Then the sas task may freed
before lldd end the interrupt process. Thus a use-after-free will happen.

Fix this by calling the complete() only when SAS_TASK_STATE_DONE is not
set. And remove the check of the return value of the del_timer(). Once the
LLDD sets DONE, it must call task-&gt;done(), which will call
smp_task_done()-&gt;complete() and the task will be completed and freed
correctly.

Reported-by: chenxiang &lt;chenxiang66@hisilicon.com&gt;
Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
CC: John Garry &lt;john.garry@huawei.com&gt;
CC: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
CC: Ewan Milne &lt;emilne@redhat.com&gt;
CC: Christoph Hellwig &lt;hch@lst.de&gt;
CC: Tomas Henzl &lt;thenzl@redhat.com&gt;
CC: Dan Williams &lt;dan.j.williams@intel.com&gt;
CC: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: John Garry &lt;john.garry@huawei.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: virtio_scsi: don't send sc payload with tmfs</title>
<updated>2019-07-09T21:04:13+00:00</updated>
<author>
<name>Felipe Franciosi</name>
<email>felipe@nutanix.com</email>
</author>
<published>2019-02-27T16:10:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=15ae3ceed024acbfa43779c4ff0d573faf4aa53f'/>
<id>15ae3ceed024acbfa43779c4ff0d573faf4aa53f</id>
<content type='text'>
commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.

The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of
device-readable records and a single device-writable response entry:

    struct virtio_scsi_ctrl_tmf
    {
        // Device-readable part
        le32 type;
        le32 subtype;
        u8 lun[8];
        le64 id;
        // Device-writable part
        u8 response;
    }

The above should be organised as two descriptor entries (or potentially
more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64
id" or after "u8 response".

The Linux driver doesn't respect that, with virtscsi_abort() and
virtscsi_device_reset() setting cmd-&gt;sc before calling virtscsi_tmf().  It
results in the original scsi command payload (or writable buffers) added to
the tmf.

This fixes the problem by leaving cmd-&gt;sc zeroed out, which makes
virtscsi_kick_cmd() add the tmf to the control vq without any payload.

Signed-off-by: Felipe Franciosi &lt;felipe@nutanix.com&gt;
Reviewed-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3722e6a52174d7c3a00e6f5efd006ca093f346c1 upstream.

The virtio scsi spec defines struct virtio_scsi_ctrl_tmf as a set of
device-readable records and a single device-writable response entry:

    struct virtio_scsi_ctrl_tmf
    {
        // Device-readable part
        le32 type;
        le32 subtype;
        u8 lun[8];
        le64 id;
        // Device-writable part
        u8 response;
    }

The above should be organised as two descriptor entries (or potentially
more if using VIRTIO_F_ANY_LAYOUT), but without any extra data after "le64
id" or after "u8 response".

The Linux driver doesn't respect that, with virtscsi_abort() and
virtscsi_device_reset() setting cmd-&gt;sc before calling virtscsi_tmf().  It
results in the original scsi command payload (or writable buffers) added to
the tmf.

This fixes the problem by leaving cmd-&gt;sc zeroed out, which makes
virtscsi_kick_cmd() add the tmf to the control vq without any payload.

Signed-off-by: Felipe Franciosi &lt;felipe@nutanix.com&gt;
Reviewed-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: megaraid_sas: return error when create DMA pool failed</title>
<updated>2019-06-20T17:11:27+00:00</updated>
<author>
<name>Jason Yan</name>
<email>yanaijie@huawei.com</email>
</author>
<published>2019-02-15T11:50:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd0908fbd84009cb5f01cf1a258a6f7fd78b6b3a'/>
<id>bd0908fbd84009cb5f01cf1a258a6f7fd78b6b3a</id>
<content type='text'>
commit bcf3b67d16a4c8ffae0aa79de5853435e683945c upstream.

when create DMA pool for cmd frames failed, we should return -ENOMEM,
instead of 0.
In some case in:

    megasas_init_adapter_fusion()

    --&gt;megasas_alloc_cmds()
       --&gt;megasas_create_frame_pool
          create DMA pool failed,
        --&gt; megasas_free_cmds() [1]

    --&gt;megasas_alloc_cmds_fusion()
       failed, then goto fail_alloc_cmds.
    --&gt;megasas_free_cmds() [2]

we will call megasas_free_cmds twice, [1] will kfree cmd_list,
[2] will use cmd_list.it will cause a problem:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = ffffffc000f70000
[00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003,
*pmd=0000001fbf894003, *pte=006000006d000707
Internal error: Oops: 96000005 [#1] SMP
 Modules linked in:
 CPU: 18 PID: 1 Comm: swapper/0 Not tainted
 task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000
 PC is at megasas_free_cmds+0x30/0x70
 LR is at megasas_free_cmds+0x24/0x70
 ...
 Call trace:
 [&lt;ffffffc0005b779c&gt;] megasas_free_cmds+0x30/0x70
 [&lt;ffffffc0005bca74&gt;] megasas_init_adapter_fusion+0x2f4/0x4d8
 [&lt;ffffffc0005b926c&gt;] megasas_init_fw+0x2dc/0x760
 [&lt;ffffffc0005b9ab0&gt;] megasas_probe_one+0x3c0/0xcd8
 [&lt;ffffffc0004a5abc&gt;] local_pci_probe+0x4c/0xb4
 [&lt;ffffffc0004a5c40&gt;] pci_device_probe+0x11c/0x14c
 [&lt;ffffffc00053a5e4&gt;] driver_probe_device+0x1ec/0x430
 [&lt;ffffffc00053a92c&gt;] __driver_attach+0xa8/0xb0
 [&lt;ffffffc000538178&gt;] bus_for_each_dev+0x74/0xc8
  [&lt;ffffffc000539e88&gt;] driver_attach+0x28/0x34
 [&lt;ffffffc000539a18&gt;] bus_add_driver+0x16c/0x248
 [&lt;ffffffc00053b234&gt;] driver_register+0x6c/0x138
 [&lt;ffffffc0004a5350&gt;] __pci_register_driver+0x5c/0x6c
 [&lt;ffffffc000ce3868&gt;] megasas_init+0xc0/0x1a8
 [&lt;ffffffc000082a58&gt;] do_one_initcall+0xe8/0x1ec
 [&lt;ffffffc000ca7be8&gt;] kernel_init_freeable+0x1c8/0x284
 [&lt;ffffffc0008d90b8&gt;] kernel_init+0x1c/0xe4

Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
Acked-by: Sumit Saxena &lt;sumit.saxena@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bcf3b67d16a4c8ffae0aa79de5853435e683945c upstream.

when create DMA pool for cmd frames failed, we should return -ENOMEM,
instead of 0.
In some case in:

    megasas_init_adapter_fusion()

    --&gt;megasas_alloc_cmds()
       --&gt;megasas_create_frame_pool
          create DMA pool failed,
        --&gt; megasas_free_cmds() [1]

    --&gt;megasas_alloc_cmds_fusion()
       failed, then goto fail_alloc_cmds.
    --&gt;megasas_free_cmds() [2]

we will call megasas_free_cmds twice, [1] will kfree cmd_list,
[2] will use cmd_list.it will cause a problem:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = ffffffc000f70000
[00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003,
*pmd=0000001fbf894003, *pte=006000006d000707
Internal error: Oops: 96000005 [#1] SMP
 Modules linked in:
 CPU: 18 PID: 1 Comm: swapper/0 Not tainted
 task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000
 PC is at megasas_free_cmds+0x30/0x70
 LR is at megasas_free_cmds+0x24/0x70
 ...
 Call trace:
 [&lt;ffffffc0005b779c&gt;] megasas_free_cmds+0x30/0x70
 [&lt;ffffffc0005bca74&gt;] megasas_init_adapter_fusion+0x2f4/0x4d8
 [&lt;ffffffc0005b926c&gt;] megasas_init_fw+0x2dc/0x760
 [&lt;ffffffc0005b9ab0&gt;] megasas_probe_one+0x3c0/0xcd8
 [&lt;ffffffc0004a5abc&gt;] local_pci_probe+0x4c/0xb4
 [&lt;ffffffc0004a5c40&gt;] pci_device_probe+0x11c/0x14c
 [&lt;ffffffc00053a5e4&gt;] driver_probe_device+0x1ec/0x430
 [&lt;ffffffc00053a92c&gt;] __driver_attach+0xa8/0xb0
 [&lt;ffffffc000538178&gt;] bus_for_each_dev+0x74/0xc8
  [&lt;ffffffc000539e88&gt;] driver_attach+0x28/0x34
 [&lt;ffffffc000539a18&gt;] bus_add_driver+0x16c/0x248
 [&lt;ffffffc00053b234&gt;] driver_register+0x6c/0x138
 [&lt;ffffffc0004a5350&gt;] __pci_register_driver+0x5c/0x6c
 [&lt;ffffffc000ce3868&gt;] megasas_init+0xc0/0x1a8
 [&lt;ffffffc000082a58&gt;] do_one_initcall+0xe8/0x1ec
 [&lt;ffffffc000ca7be8&gt;] kernel_init_freeable+0x1c8/0x284
 [&lt;ffffffc0008d90b8&gt;] kernel_init+0x1c/0xe4

Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
Acked-by: Sumit Saxena &lt;sumit.saxena@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
