- 27 Nov, 2019 6 commits
-
-
Damien Le Moal authored
In the case of a report zones command failure, instead of simply printing the host_byte and driver_byte values returned, print a message that is more human readable and useful, adding sense codes too. To do so, use the already defined sd_print_sense_hdr() and sd_print_result() functions by moving the declaration of these functions into sd.h. Link: https://lore.kernel.org/r/20191125070518.951717-1-damien.lemoal@wdc.comSigned-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Huacai Chen authored
Commit 4fa18345 ("scsi: qla2xxx: Utilize pci_alloc_irq_vectors/ pci_free_irq_vectors calls.") use pci_alloc_irq_vectors() to replace pci_enable_msi() but it didn't handle the return value correctly. This bug make qla2x00 always fail to setup MSI if MSI-X fail, so fix it. BTW, improve the log message of return value in qla2x00_request_irqs() to avoid confusion. Fixes: 4fa18345 ("scsi: qla2xxx: Utilize pci_alloc_irq_vectors/pci_free_irq_vectors calls.") Cc: Michael Hernandez <michael.hernandez@cavium.com> Link: https://lore.kernel.org/r/1574314847-14280-1-git-send-email-chenhc@lemote.comSigned-off-by:
Huacai Chen <chenhc@lemote.com> Acked-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Martin Wilck authored
When ports are lost due to unzoning them, and the initiator port is not part of any more zones, the GPN_FT command used for the fabric scan may fail. In this case, the current code simply gives up after a few retries. But if the zone is gone, all rports should actually be marked as lost. Fix this by jumping to the code that handles logout after GNN_FT after scan retries are exhausted. Fixes: f352eeb7 ("scsi: qla2xxx: Add ability to use GPNFT/GNNFT for RSCN handling") Link: https://lore.kernel.org/r/20191122221912.20100-3-martin.wilck@suse.comTested-by:
Jason Orendorf <orendorf@hpe.com> Signed-off-by:
Martin Wilck <mwilck@suse.com> Acked-by:
-
Martin Wilck authored
In qla2x00_find_all_fabric_devs(), fcport->flags & FCF_LOGIN_NEEDED is a necessary condition for logging into new rports, but not for dropping lost ones. Fixes: 726b8548 ("qla2xxx: Add framework for async fabric discovery") Link: https://lore.kernel.org/r/20191122221912.20100-2-martin.wilck@suse.comTested-by:
David Bond <dbond@suse.com> Signed-off-by:
-
YueHaibing authored
Remove #include <linux/version.h>. Don't need it. Link: https://lore.kernel.org/r/20191122020911.33269-1-yuehaibing@huawei.comSigned-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
-
Colin Ian King authored
The condition (reg_val != 2) || (reg_val != 3) will always be true because reg_val cannot be equal to two different values at the same time. Fix this by replacing the || operator with && so that the loop will loop if reg_val is not a 2 and not a 3 as was originally intended. Fixes: 50dc2f221455 ("scsi: pm80xx: Modified the logic to collect fatal dump") Link: https://lore.kernel.org/r/20191120135031.270708-1-colin.king@canonical.com Addresses-Coverity: ("Constant expression result") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
-
- 22 Nov, 2019 3 commits
-
-
John Garry authored
Removing a non-host rphy causes a memory leak: root@(none)$ echo 0 > /sys/devices/platform/HISI0162:01/host0/port-0:0/expander-0:0/port-0:0:10/phy-0:0:10/sas_phy/phy-0:0:10/enable [ 79.857888] hisi_sas_v2_hw HISI0162:01: dev[7:1] is gone root@(none)$ echo scan > /sys/kernel/debug/kmemleak [ 131.656603] kmemleak: 3 new suspected memory leaks (see /sys/kernel/debug/kmemleak) root@(none)$ more /sys/kernel/debug/kmemleak unreferenced object 0xffff041da5c66000 (size 256): comm "kworker/u128:1", pid 549, jiffies 4294898543 (age 113.728s) hex dump (first 32 bytes): 00 5e c6 a5 1d 04 ff ff 01 00 00 00 00 00 00 00 .^.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<(____ptrval____)>] kmem_cache_alloc+0x188/0x260 [<(____ptrval____)>] bsg_setup_queue+0x48/0x1a8 [<(____ptrval____)>] sas_rphy_add+0x108/0x2d0 [<(____ptrval____)>] sas_probe_devices+0x168/0x208 [<(____ptrval____)>] sas_discover_domain+0x660/0x9c8 [<(____ptrval____)>] process_one_work+0x3f8/0x690 [<(____ptrval____)>] worker_thread+0x70/0x6a0 [<(____ptrval____)>] kthread+0x1b8/0x1c0 [<(____ptrval____)>] ret_from_fork+0x10/0x18 unreferenced object 0xffff041d8c075400 (size 128): comm "kworker/u128:1", pid 549, jiffies 4294898543 (age 113.728s) hex dump (first 32 bytes): 00 40 25 97 1d 00 ff ff 00 00 00 00 00 00 00 00 .@%............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<(____ptrval____)>] __kmalloc_node+0x1a8/0x2c8 [<(____ptrval____)>] blk_mq_realloc_tag_set_tags.part.70+0x48/0xd8 [<(____ptrval____)>] blk_mq_alloc_tag_set+0x1dc/0x530 [<(____ptrval____)>] bsg_setup_queue+0xe8/0x1a8 [<(____ptrval____)>] sas_rphy_add+0x108/0x2d0 [<(____ptrval____)>] sas_probe_devices+0x168/0x208 [<(____ptrval____)>] sas_discover_domain+0x660/0x9c8 [<(____ptrval____)>] process_one_work+0x3f8/0x690 [<(____ptrval____)>] worker_thread+0x70/0x6a0 [<(____ptrval____)>] kthread+0x1b8/0x1c0 [<(____ptrval____)>] ret_from_fork+0x10/0x18 unreferenced object 0xffff041da5c65e00 (size 256): comm "kworker/u128:1", pid 549, jiffies 4294898543 (age 113.728s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<(____ptrval____)>] __kmalloc_node+0x1a8/0x2c8 [<(____ptrval____)>] blk_mq_alloc_tag_set+0x254/0x530 [<(____ptrval____)>] bsg_setup_queue+0xe8/0x1a8 [<(____ptrval____)>] sas_rphy_add+0x108/0x2d0 [<(____ptrval____)>] sas_probe_devices+0x168/0x208 [<(____ptrval____)>] sas_discover_domain+0x660/0x9c8 [<(____ptrval____)>] process_one_work+0x3f8/0x690 [<(____ptrval____)>] worker_thread+0x70/0x6a0 [<(____ptrval____)>] kthread+0x1b8/0x1c0 [<(____ptrval____)>] ret_from_fork+0x10/0x18 root@(none)$ It turns out that we don't clean up the request queue fully for bsg devices, as the blk mq tags for the request queue are not freed. Fix by doing the queue removal in one place - in sas_rphy_remove() - instead of unregistering the queue in sas_rphy_remove() and finally cleaning up the queue in calling blk_cleanup_queue() from sas_end_device_release() or sas_expander_release(). Function bsg_remove_queue() can handle a NULL pointer q, so remove the precheck in sas_rphy_remove(). Fixes: 651a0136 ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough") Link: https://lore.kernel.org/r/1574242755-94156-1-git-send-email-john.garry@huawei.comSigned-off-by:John Garry <john.garry@huawei.com> Signed-off-by:
-
James Smart authored
Currently the lpfc driver sizes its cpu_map array based on num_possible_cpus(). However, that can be a value that is less than the highest cpu id bit that is set. As such, if a thread runs on a cpu with a larger cpu id, or for_each_possible_cpu() is used, the driver could index off the end of the array and return garbage or GPF. The driver maintains its own internal copy of the "num_possible" cpu value and sizes arrays by it. Fix by setting the driver's value to the value of the last cpu id bit set in the possible_mask - plus 1. Thus cpu_map will be sized to allow access by any cpu id possible. Link: https://lore.kernel.org/r/20191121175556.18953-1-jsmart2021@gmail.comSigned-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Saurav Girepunje authored
Variable rc is not modified in ibmvscsis_srp_i_logout function. So remove unneeded variable rc. Issue found using coccicheck tool. Link: https://lore.kernel.org/r/20191101120407.GA9369@sauravSigned-off-by:
Saurav Girepunje <saurav.girepunje@gmail.com> Reviewed-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
-
- 20 Nov, 2019 31 commits
-
-
Laurence Oberman authored
In the bnx2fc_eh_abort() function there is a calculation for wait_for_completion that uses a HZ multiplier. This is incorrect, it scales the timeout by 1000 seconds instead of converting the ms value to jiffies. Therefore change the calculation. Link: https://lore.kernel.org/r/1574178394-16635-1-git-send-email-loberman@redhat.comReported-by:
David Jeffery <djeffery@redhat.com> Reviewed-by:
John Pittman <jpittman@redhat.com> Reviewed-by:
Chad Dupuis <cdupuis1@gmail.com> Signed-off-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
-
Bart Van Assche authored
Print the string for which conversion failed instead of printing the function name twice. Fixes: 2650d71e ("target: move transport ID handling to the core") Cc: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20191107215525.64415-1-bvanassche@acm.orgSigned-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Anatol Pomazau authored
If a faulty initiator fails to bind the socket to the iSCSI connection before emitting a command, for instance, a subsequent send_pdu, it will crash the kernel due to a null pointer dereference in sock_sendmsg(), as shown in the log below. This patch makes sure the bind succeeded before trying to use the socket. BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.4.0-rc2.iscsi+ #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 24.158246] Workqueue: iscsi_q_0 iscsi_xmitworker [ 24.158883] RIP: 0010:apparmor_socket_sendmsg+0x5/0x20 [...] [ 24.161739] RSP: 0018:ffffab6440043ca0 EFLAGS: 00010282 [ 24.162400] RAX: ffffffff891c1c00 RBX: ffffffff89d53968 RCX: 0000000000000001 [ 24.163253] RDX: 0000000000000030 RSI: ffffab6440043d00 RDI: 0000000000000000 [ 24.164104] RBP: 0000000000000030 R08: 0000000000000030 R09: 0000000000000030 [ 24.165166] R10: ffffffff893e66a0 R11: 0000000000000018 R12: ffffab6440043d00 [ 24.166038] R13: 0000000000000000 R14: 0000000000000000 R15: ffff9d5575a62e90 [ 24.166919] FS: 0000000000000000(0000) GS:ffff9d557db80000(0000) knlGS:0000000000000000 [ 24.167890] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.168587] CR2: 0000000000000018 CR3: 000000007a838000 CR4: 00000000000006e0 [ 24.169451] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 24.170320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 24.171214] Call Trace: [ 24.171537] security_socket_sendmsg+0x3a/0x50 [ 24.172079] sock_sendmsg+0x16/0x60 [ 24.172506] iscsi_sw_tcp_xmit_segment+0x77/0x120 [ 24.173076] iscsi_sw_tcp_pdu_xmit+0x58/0x170 [ 24.173604] ? iscsi_dbg_trace+0x63/0x80 [ 24.174087] iscsi_tcp_task_xmit+0x101/0x280 [ 24.174666] iscsi_xmit_task+0x83/0x110 [ 24.175206] iscsi_xmitworker+0x57/0x380 [ 24.175757] ? __schedule+0x2a2/0x700 [ 24.176273] process_one_work+0x1b5/0x360 [ 24.176837] worker_thread+0x50/0x3c0 [ 24.177353] kthread+0xf9/0x130 [ 24.177799] ? process_one_work+0x360/0x360 [ 24.178401] ? kthread_park+0x90/0x90 [ 24.178915] ret_from_fork+0x35/0x40 [ 24.179421] Modules linked in: [ 24.179856] CR2: 0000000000000018 [ 24.180327] ---[ end trace b4b7674b6df5f480 ]--- Signed-off-by:
Anatol Pomazau <anatol@google.com> Co-developed-by:
Frank Mayhar <fmayhar@google.com> Signed-off-by:
Bharath Ravi <rbharath@google.com> Signed-off-by:
Khazhimsel Kumykov <khazhy@google.com> Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.com> Signed-off-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
-
Bart Van Assche authored
The iSCSI target driver is the only target driver that does not wait for ongoing commands to finish before freeing a session. Make the iSCSI target driver wait for ongoing commands to finish before freeing a session. This patch fixes the following KASAN complaint: BUG: KASAN: use-after-free in __lock_acquire+0xb1a/0x2710 Read of size 8 at addr ffff8881154eca70 by task kworker/0:2/247 CPU: 0 PID: 247 Comm: kworker/0:2 Not tainted 5.4.0-rc1-dbg+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: target_completion target_complete_ok_work [target_core_mod] Call Trace: dump_stack+0x8a/0xd6 print_address_description.constprop.0+0x40/0x60 __kasan_report.cold+0x1b/0x33 kasan_report+0x16/0x20 __asan_load8+0x58/0x90 __lock_acquire+0xb1a/0x2710 lock_acquire+0xd3/0x200 _raw_spin_lock_irqsave+0x43/0x60 target_release_cmd_kref+0x162/0x7f0 [target_core_mod] target_put_sess_cmd+0x2e/0x40 [target_core_mod] lio_check_stop_free+0x12/0x20 [iscsi_target_mod] transport_cmd_check_stop_to_fabric+0xd8/0xe0 [target_core_mod] target_complete_ok_work+0x1b0/0x790 [target_core_mod] process_one_work+0x549/0xa40 worker_thread+0x7a/0x5d0 kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Allocated by task 889: save_stack+0x23/0x90 __kasan_kmalloc.constprop.0+0xcf/0xe0 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xf6/0x360 transport_alloc_session+0x29/0x80 [target_core_mod] iscsi_target_login_thread+0xcd6/0x18f0 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Freed by task 1025: save_stack+0x23/0x90 __kasan_slab_free+0x13a/0x190 kasan_slab_free+0x12/0x20 kmem_cache_free+0x146/0x400 transport_free_session+0x179/0x2f0 [target_core_mod] transport_deregister_session+0x130/0x180 [target_core_mod] iscsit_close_session+0x12c/0x350 [iscsi_target_mod] iscsit_logout_post_handler+0x136/0x380 [iscsi_target_mod] iscsit_response_queue+0x8de/0xbe0 [iscsi_target_mod] iscsi_target_tx_thread+0x27f/0x370 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 The buggy address belongs to the object at ffff8881154ec9c0 which belongs to the cache se_sess_cache of size 352 The buggy address is located 176 bytes inside of 352-byte region [ffff8881154ec9c0, ffff8881154ecb20) The buggy address belongs to the page: page:ffffea0004553b00 refcount:1 mapcount:0 mapping:ffff888101755400 index:0x0 compound_mapcount: 0 flags: 0x2fff000000010200(slab|head) raw: 2fff000000010200 dead000000000100 dead000000000122 ffff888101755400 raw: 0000000000000000 0000000080130013 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881154ec900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881154ec980: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb >ffff8881154eca00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881154eca80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881154ecb00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc Cc: Mike Christie <mchristi@redhat.com> Link: https://lore.kernel.org/r/20191113220508.198257-3-bvanassche@acm.orgReviewed-by:Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
-
Bart Van Assche authored
The SCSI specs require releasing SPC-2 reservations when a session is closed. Make sure that the target core does this. Running the libiscsi tests triggers the KASAN complaint shown below. This patch fixes that use-after-free. BUG: KASAN: use-after-free in target_check_reservation+0x171/0x980 [target_core_mod] Read of size 8 at addr ffff88802ecd1878 by task iscsi_trx/17200 CPU: 0 PID: 17200 Comm: iscsi_trx Not tainted 5.4.0-rc1-dbg+ #1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x8a/0xd6 print_address_description.constprop.0+0x40/0x60 __kasan_report.cold+0x1b/0x34 kasan_report+0x16/0x20 __asan_load8+0x58/0x90 target_check_reservation+0x171/0x980 [target_core_mod] __target_execute_cmd+0xb1/0xf0 [target_core_mod] target_execute_cmd+0x22d/0x4d0 [target_core_mod] transport_generic_new_cmd+0x31f/0x5b0 [target_core_mod] transport_handle_cdb_direct+0x6f/0x90 [target_core_mod] iscsit_execute_cmd+0x381/0x3f0 [iscsi_target_mod] iscsit_sequence_cmd+0x13b/0x1f0 [iscsi_target_mod] iscsit_process_scsi_cmd+0x4c/0x130 [iscsi_target_mod] iscsit_get_rx_pdu+0x8e8/0x15f0 [iscsi_target_mod] iscsi_target_rx_thread+0x105/0x1b0 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Allocated by task 1079: save_stack+0x23/0x90 __kasan_kmalloc.constprop.0+0xcf/0xe0 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xfe/0x3a0 transport_alloc_session+0x29/0x80 [target_core_mod] iscsi_target_login_thread+0xceb/0x1920 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Freed by task 17193: save_stack+0x23/0x90 __kasan_slab_free+0x13a/0x190 kasan_slab_free+0x12/0x20 kmem_cache_free+0xc8/0x3e0 transport_free_session+0x179/0x2f0 [target_core_mod] transport_deregister_session+0x121/0x170 [target_core_mod] iscsit_close_session+0x12c/0x350 [iscsi_target_mod] iscsit_logout_post_handler+0x136/0x380 [iscsi_target_mod] iscsit_response_queue+0x8fa/0xc00 [iscsi_target_mod] iscsi_target_tx_thread+0x28e/0x390 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 The buggy address belongs to the object at ffff88802ecd1860 which belongs to the cache se_sess_cache of size 352 The buggy address is located 24 bytes inside of 352-byte region [ffff88802ecd1860, ffff88802ecd19c0) The buggy address belongs to the page: page:ffffea0000bb3400 refcount:1 mapcount:0 mapping:ffff8880bef2ed00 index:0x0 compound_mapcount: 0 flags: 0x1000000000010200(slab|head) raw: 1000000000010200 dead000000000100 dead000000000122 ffff8880bef2ed00 raw: 0000000000000000 0000000080270027 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88802ecd1700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88802ecd1780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88802ecd1800: fb fb fb fb fc fc fc fc fc fc fc fc fb fb fb fb ^ ffff88802ecd1880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88802ecd1900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Cc: Mike Christie <mchristi@redhat.com> Link: https://lore.kernel.org/r/20191113220508.198257-2-bvanassche@acm.orgReviewed-by: -
Bart Van Assche authored
Since it is nontrivial to derive the meaning of the size argument from the code, add a documentation header above target_cmd_size_check(). Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Link: https://lore.kernel.org/r/20191107215458.64242-1-bvanassche@acm.orgSigned-off-by:
-
Pan Bian authored
The member hba->pcidev may be used after its reference is dropped. Move the put function to where it is never used to avoid potential use after free issues. Fixes: a7717180 ("[SCSI] bnx2i: Removed the reference to the netdev->base_addr") Link: https://lore.kernel.org/r/1573043541-19126-1-git-send-email-bianpan2016@163.comSigned-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
-
Martin K. Petersen authored
This reverts commit 2f856d4e. This patch was found to introduce a double free regression. The issue it originally attempted to address was fixed in patch f45bca8c ("scsi: qla2xxx: Fix double scsi_done for abort path"). Link: https://lore.kernel.org/r/4BDE2B95-835F-43BE-A32C-2629D7E03E0A@marvell.comRequested-by:
-
Finn Thain authored
Add a module parameter to inhibit disconnect/reselect for individual targets. This gains compatibility with Aztec PowerMonster SCSI/SATA adapters with buggy firmware. (No fix is available from the vendor.) Apparently these adapters pass-through the product/vendor of the attached SATA device. Since they can't be identified from the response to an INQUIRY command, a device blacklist flag won't work. Cc: Michael Schmitz <schmitzmic@gmail.com> Link: https://lore.kernel.org/r/993b17545990f31f9fa5a98202b51102a68e7594.1573875417.git.fthain@telegraphics.com.auReviewed-and-tested-by:
Michael Schmitz <schmitzmic@gmail.com> Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
-
Finn Thain authored
When do_abort() succeeds, the target will go to BUS FREE phase and there will be no connected command. Therefore, that function should clear the Initiator Command Register before returning. It already does so in case of NCR5380_poll_politely() failure; do the same for the other error case too, that is, NCR5380_transfer_pio() failure. Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: Ondrej Zary <linux@zary.sk> Link: https://lore.kernel.org/r/4277b28ee2551f884aefa85965ef3c498344f301.1573875417.git.fthain@telegraphics.com.auReviewed-and-tested-by:
Ondrej Zary <linux@zary.sk> Signed-off-by:
-
Finn Thain authored
Most NCR5380 drivers calculate the residual for every data transfer. (A few drivers just set it to zero.) Pass this quantity back to the scsi mid-layer on command completion. Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: Ondrej Zary <linux@zary.sk> Link: https://lore.kernel.org/r/1f26ead9dd0dc053fcd27979d69a7ca74b6589b4.1573875417.git.fthain@telegraphics.com.auReviewed-and-tested-by:
-
Maurizio Lombardi authored
Passing the parameter "num_tgts=-1" will start an infinite loop that exhausts the system memory Link: https://lore.kernel.org/r/20191115163727.24626-1-mlombard@redhat.comSigned-off-by:
Maurizio Lombardi <mlombard@redhat.com> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
James Smart authored
Looking at the recent conversion from smp_processor_id() to raw_smp_processor_id(), realized that the allocation should be based on the cpu the hdwq is bound to, not the executing cpu. Revise to pull cpu number from the hdwq Fixes: 765ab6cd ("scsi: lpfc: Fix a kernel warning triggered by lpfc_get_sgl_per_hdwq()") Link: https://lore.kernel.org/r/20191116003847.6141-1-jsmart2021@gmail.comSigned-off-by:
-
Colin Ian King authored
There are a few statements that are indented incorrectly, fix these. Link: https://lore.kernel.org/r/20191114180007.325856-1-colin.king@canonical.comSigned-off-by:
-
Pan Bian authored
The variable init_fw_cb is released twice, resulting in a double free bug. The call to the function dma_free_coherent() before goto is removed to get rid of potential double free. Fixes: 2a49a78e ("[SCSI] qla4xxx: added IPv6 support.") Link: https://lore.kernel.org/r/1572945927-27796-1-git-send-email-bianpan2016@163.comSigned-off-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
-
Deepak Ukey authored
Added the correct method to collect the fatal dump. Link: https://lore.kernel.org/r/20191114100910.6153-14-deepak.ukey@microchip.comReported-by:
kbuild test robot <lkp@intel.com> Acked-by:
Deepak Ukey <deepak.ukey@microchip.com> Signed-off-by:
Viswas G <Viswas.G@microchip.com> Signed-off-by:
-
Vikram Auradkar authored
With MSI-x enabled, the interrupt instances are <prefix><index> where the prefix is fixed for all module instances, making it a little harder to track down what's what. Link: https://lore.kernel.org/r/20191114100910.6153-13-deepak.ukey@microchip.comAcked-by:
Vikram Auradkar <auradkar@google.com> Signed-off-by:
-
Deepak Ukey authored
Added support to check controller fatal error through sysfs. Link: https://lore.kernel.org/r/20191114100910.6153-12-deepak.ukey@microchip.comAcked-by:
-
peter chang authored
Occasionally, 6G capable drives fail to train at 6G on links that look good from a signal-integrity perspective. PMC suggests configuring the port to not even expect 12G. Link: https://lore.kernel.org/r/20191114100910.6153-11-deepak.ukey@microchip.comAcked-by:
peter chang <dpf@google.com> Signed-off-by:
-
peter chang authored
Added the fix so the if driver properly sent the abort it tries to remove it from the firmware's list of outstanding commands regardless of the abort status. This means that the task gets freed 'now' rather than possibly getting freed later when the scsi layer thinks it's leaked but still valid. Link: https://lore.kernel.org/r/20191114100910.6153-10-deepak.ukey@microchip.comAcked-by:
-
peter chang authored
The commands to the controller are sent in fixed sized chunks which are set per-chip-generation and stashed in iomb_size. The driver fills in structs matching the register layout and memcpy this to memory shared with the controller. However, there are two problem cases: 1) Things like phy_start_req are too large because they share the sas_identify_frame definition with libsas, and it includes the crc word. This means that it's overwriting the start of the next command block, that's ok except if it happens at the end of the shared memory area. 2) Things like set_nvm_data_req which are shared between the HAL layers. This means that it's sending 'random' data for things that are in the reserved area. So far we haven't found a case where the controller FW cares, but sending possible gibberish (for most of the structures this is in the reserved area so previously zeroed) is not recommended. Link: https://lore.kernel.org/r/20191114100910.6153-9-deepak.ukey@microchip.comAcked-by:
-
Vikram Auradkar authored
sas_task structure should not be used after task_done is called. If the device is gone or not attached, we call task_done on t and continue to use in the sas_task in rest of the function. task_done is pointing to sas_ata_task_done, may free the memory associated with the task before returning. Link: https://lore.kernel.org/r/20191114100910.6153-8-deepak.ukey@microchip.comAcked-by:
-
ianyar authored
The function mpi_uninit_check takes longer for inbound doorbell register to be cleared. Increased the timeout substantially so that the driver does not fail to load. Link: https://lore.kernel.org/r/20191114100910.6153-7-deepak.ukey@microchip.comAcked-by:
ianyar <ianyar@google.com> Signed-off-by:
-
peter chang authored
The default logging doesn't include the device name, so it's difficult to determine which controller is being logged about in error scenarios. The logging level was only settable via sysfs, which made it inconvenient for actual debugging. This changes the default to only cover error handling. Link: https://lore.kernel.org/r/20191114100910.6153-6-deepak.ukey@microchip.comAcked-by:
-
Vikram Auradkar authored
For delays longer than 20ms [um]delay isn't recommended. pm80xx_chip_soft_rst starts off with a 500ms delay before it even gets around to checking for the results of the reset. As long as it's at least 500ms it doesn't matter what the scheduler is doing. The delay in the pm8001_exec_internal_task_abort does nothing, and theory is this is a delay to avoid a double-free. Link: https://lore.kernel.org/r/20191114100910.6153-5-deepak.ukey@microchip.comAcked-by:
-
John Sperbeck authored
In pm8001_task_exec(), if the PHY is down, then we return the current value of 'rc'. We need to make sure it's initialized. Link: https://lore.kernel.org/r/20191114100910.6153-4-deepak.ukey@microchip.comAcked-by:
John Sperbeck <jsperbeck@google.com> Signed-off-by:
-
peter chang authored
After the completing the mpi_phy_start_resp, make phy enable completion as NULL. Link: https://lore.kernel.org/r/20191114100910.6153-3-deepak.ukey@microchip.comAcked-by:
-
peter chang authored
Driver was missing complete() call in mpi_sata_completion which result in SATA abort error handling timing out. That causes the device to be left in the in_recovery state so subsequent commands sent to the device fail and the OS removes access to it. Link: https://lore.kernel.org/r/20191114100910.6153-2-deepak.ukey@microchip.comAcked-by:
-
Subhash Jadavani authored
During clock gating (ufshcd_gate_work()), we first put the link hibern8 by calling ufshcd_uic_hibern8_enter() and if ufshcd_uic_hibern8_enter() returns success (0) then we gate all the clocks. Now let’s zoom in to what ufshcd_uic_hibern8_enter() does internally: It calls __ufshcd_uic_hibern8_enter() and if failure is encountered, link recovery shall put the link back to the highest HS gear and returns success (0) to ufshcd_uic_hibern8_enter() which is the issue as link is still in active state due to recovery! Now ufshcd_uic_hibern8_enter() returns success to ufshcd_gate_work() and hence it goes ahead with gating the UFS clock while link is still in active state hence I believe controller would raise UIC error interrupts. But when we service the interrupt, clocks might have already been disabled! This change fixes for this by returning failure from __ufshcd_uic_hibern8_enter() if recovery succeeds as link is still not in hibern8, upon receiving the error ufshcd_hibern8_enter() would initiate retry to put the link state back into hibern8. Link: https://lore.kernel.org/r/1573798172-20534-8-git-send-email-cang@codeaurora.orgReviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
-
Asutosh Das authored
This change attempts to abort gating of clocks if a request to turn-on clocks is pending. This would in turn avoid turning OFF and back ON the clocks. Link: https://lore.kernel.org/r/1573798172-20534-7-git-send-email-cang@codeaurora.orgReviewed-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
-
Venkat Gopalakrishnan authored
Return IRQ_HANDLED only if the irq is really handled, this will help in catching spurious interrupts that go unhandled. Link: https://lore.kernel.org/r/1573798172-20534-6-git-send-email-cang@codeaurora.orgReviewed-by:
Venkat Gopalakrishnan <venkatg@codeaurora.org> Signed-off-by:
-
