- 06 Apr, 2021 2 commits
-
-
Roman Bolshakov authored
target_sequencer_start event is triggered inside target_cmd_init_cdb(). se_cmd.tag is not initialized with ITT at the moment so the event always prints zero tag. Link: https://lore.kernel.org/r/20210403215415.95077-1-r.bolshakov@yadro.com Cc: stable@vger.kernel.org # 5.10+ Reviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Viswas G authored
Inbound and outbound queues were not properly configured and that lead to MPI configuration failure. Fixes: 05c6c029 ("scsi: pm80xx: Increase number of supported queues") Cc: stable@vger.kernel.org # 5.10+ Link: https://lore.kernel.org/r/20210402054212.17834-1-Viswas.G@microchip.com.comReported-and-tested-by:
Ash Izat <ash@ai0.uk> Signed-off-by:
Viswas G <Viswas.G@microchip.com> Signed-off-by:
-
- 02 Apr, 2021 5 commits
-
-
Can Guo authored
In __ufshcd_issue_tm_cmd(), it is not correct to use hba->nutrs + req->tag as the Task Tag in a TMR UPIU. Directly use req->tag as the Task Tag. Fixes: e2933132 ("scsi: ufs: Fix broken task management command implementation") Link: https://lore.kernel.org/r/1617262750-4864-3-git-send-email-cang@codeaurora.orgReviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
-
Can Guo authored
ufshcd_tmc_handler() calls blk_mq_tagset_busy_iter(fn = ufshcd_compl_tm()), but since blk_mq_tagset_busy_iter() only iterates over all reserved tags and requests which are not in IDLE state, ufshcd_compl_tm() never gets a chance to run. Thus, TMR always ends up with completion timeout. Fix it by calling blk_mq_start_request() in __ufshcd_issue_tm_cmd(). Link: https://lore.kernel.org/r/1617262750-4864-2-git-send-email-cang@codeaurora.org Fixes: 69a6c269 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs") Reviewed-by:
-
Sergei Trofimovich authored
Link: https://lore.kernel.org/r/20210330071958.3788214-3-slyfox@gentoo.org Fixes: f749d8b7 ("scsi: hpsa: Correct dev cmds outstanding for retried cmds") CC: linux-ia64@vger.kernel.org CC: storagedev@microchip.com CC: linux-scsi@vger.kernel.org CC: Joe Szczypek <jszczype@redhat.com> CC: Scott Benesh <scott.benesh@microchip.com> CC: Scott Teel <scott.teel@microchip.com> CC: Tomas Henzl <thenzl@redhat.com> CC: "Martin K. Petersen" <martin.petersen@oracle.com> CC: Don Brace <don.brace@microchip.com> Reported-by:
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Suggested-by:
Don Brace <don.brace@microchip.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sergei Trofimovich <slyfox@gentoo.org> Signed-off-by:
-
Sergei Trofimovich authored
Boot failure was observed on an HP rx3600 ia64 machine with RAID bus controller: Hewlett-Packard Company Smart Array P600: kernel unaligned access to 0xe000000105dd8b95, ip=0xa000000100b87551 kernel unaligned access to 0xe000000105dd8e95, ip=0xa000000100b87551 hpsa 0000:14:01.0: Controller reports max supported commands of 0 Using 16 instead. Ensure that firmware is up to date. swapper/0[1]: error during unaligned kernel access The unaligned access comes from 'struct CommandList' that happens to be packed. Commit f749d8b7 ("scsi: hpsa: Correct dev cmds outstanding for retried cmds") introduced unexpected padding and unaligned atomic_t from natural alignment to something else. This change removes packing annotation from a struct not intended to be sent to controller as is. This restores natural `atomic_t` alignment. The change was tested on the same rx3600 machine. Link: https://lore.kernel.org/r/20210330071958.3788214-2-slyfox@gentoo.org Fixes: f749d8b7 ("scsi: hpsa: Correct dev cmds outstanding for retried cmds") CC: linux-ia64@vger.kernel.org CC: linux-kernel@vger.kernel.org CC: storagedev@microchip.com CC: linux-scsi@vger.kernel.org CC: Joe Szczypek <jszczype@redhat.com> CC: Scott Benesh <scott.benesh@microchip.com> CC: Scott Teel <scott.teel@microchip.com> CC: Tomas Henzl <thenzl@redhat.com> CC: "Martin K. Petersen" <martin.petersen@oracle.com> CC: Don Brace <don.brace@microchip.com> Reported-by: -
Sergei Trofimovich authored
The hpsa driver uses data structures which contain a combination of driver internals and commands sent directly to the hardware. To manage alignment for the hardware portions the driver used #pragma pack(1). Commit f749d8b7 ("scsi: hpsa: Correct dev cmds outstanding for retried cmds") switched an existing variable from int to bool. Due to the pragma an atomic_t in the same data structure ended up being misaligned and broke boot on ia64. Add __packed to every struct and union in the header file. Subsequent commits will address the actual atomic_t misalignment regression. The commit is a no-op at least on ia64: $ diff -u <(objdump -d -r old.o) <(objdump -d -r new.o) Link: https://lore.kernel.org/r/20210330071958.3788214-1-slyfox@gentoo.org Fixes: f749d8b7 ("scsi: hpsa: Correct dev cmds outstanding for retried cmds") CC: linux-ia64@vger.kernel.org CC: storagedev@microchip.com CC: linux-scsi@vger.kernel.org CC: Joe Szczypek <jszczype@redhat.com> CC: Scott Benesh <scott.benesh@microchip.com> CC: Scott Teel <scott.teel@microchip.com> CC: Tomas Henzl <thenzl@redhat.com> CC: "Martin K. Petersen" <martin.petersen@oracle.com> CC: Don Brace <don.brace@microchip.com> Reported-by:
-
- 30 Mar, 2021 1 commit
-
-
Gulam Mohamed authored
A kernel panic was observed due to a timing issue between the sync thread and the initiator processing a login response from the target. The session reopen can be invoked both from the session sync thread when iscsid restarts and from iscsid through the error handler. Before the initiator receives the response to a login, another reopen request can be sent from the error handler/sync session. When the initial login response is subsequently processed, the connection has been closed and the socket has been released. To fix this a new connection state, ISCSI_CONN_BOUND, is added: - Set the connection state value to ISCSI_CONN_DOWN upon iscsi_if_ep_disconnect() and iscsi_if_stop_conn() - Set the connection state to the newly created value ISCSI_CONN_BOUND after bind connection (transport->bind_conn()) - In iscsi_set_param(), return -ENOTCONN if the connection state is not either ISCSI_CONN_BOUND or ISCSI_CONN_UP Link: https://lore.kernel.org/r/20210325093248.284678-1-gulam.mohamed@oracle.comReviewed-by:
Gulam Mohamed <gulam.mohamed@oracle.com> Signed-off-by:
-
- 25 Mar, 2021 7 commits
-
-
Martin Wilck authored
If pscsi_map_sg() fails, make sure to drop references to already allocated bios. Link: https://lore.kernel.org/r/20210323212431.15306-2-mwilck@suse.comReviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Martin Wilck <mwilck@suse.com> Signed-off-by:
-
Martin Wilck authored
pscsi_map_sg() uses the variable nr_pages as a hint for bio_kmalloc() how many vector elements to allocate. If nr_pages is < BIO_MAX_PAGES, it will be reset to 0 after successful allocation of the bio. If bio_add_pc_page() fails later for whatever reason, pscsi_map_sg() tries to allocate another bio, passing nr_vecs = 0. This causes bio_add_pc_page() to fail immediately in the next call. pci_map_sg() continues to allocate zero-length bios until memory is exhausted and the kernel crashes with OOM. This can be easily observed by exporting a SATA DVD drive via pscsi. The target crashes as soon as the client tries to access the DVD LUN. In the case I analyzed, bio_add_pc_page() would fail because the DVD device's max_sectors_kb (128) was exceeded. Avoid this by simply not resetting nr_pages to 0 after allocating the bio. This way, the client receives an I/O error when it tries to send requests exceeding the devices max_sectors_kb, and eventually gets it right. The client must still limit max_sectors_kb e.g. by an udev rule if (like in my case) the driver doesn't report valid block limits, otherwise it encounters I/O errors. Link: https://lore.kernel.org/r/20210323212431.15306-1-mwilck@suse.comReviewed-by:
-
Jia-Ju Bai authored
When kzalloc() returns NULL, no error return code of mpt3sas_base_attach() is assigned. To fix this bug, r is assigned with -ENOMEM in this case. Link: https://lore.kernel.org/r/20210308035241.3288-1-baijiaju1990@gmail.com Fixes: c696f7b8 ("scsi: mpt3sas: Implement device_remove_in_progress check in IOCTL path") Reported-by:
TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
-
Jia-Ju Bai authored
When kzalloc() returns NULL to qedi->global_queues[i], no error return code of qedi_alloc_global_queues() is assigned. To fix this bug, status is assigned with -ENOMEM in this case. Link: https://lore.kernel.org/r/20210308033024.27147-1-baijiaju1990@gmail.com Fixes: ace7f46b ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Reported-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
-
Bart Van Assche authored
Calling vha->hw->tgt.tgt_ops->free_cmd() from qlt_xmit_response() is wrong since the command for which a response is sent must remain valid until the SCSI target core calls .release_cmd(). It has been observed that the following scenario triggers a kernel crash: - qlt_xmit_response() calls qlt_check_reserve_free_req() - qlt_check_reserve_free_req() returns -EAGAIN - qlt_xmit_response() calls vha->hw->tgt.tgt_ops->free_cmd(cmd) - transport_handle_queue_full() tries to retransmit the response Fix this crash by reverting the patch that introduced it. Link: https://lore.kernel.org/r/20210320232359.941-2-bvanassche@acm.org Fixes: 0dcec41a ("scsi: qla2xxx: Make sure that aborted commands are freed") Cc: Quinn Tran <qutran@marvell.com> Cc: Mike Christie <michael.christie@oracle.com> Reviewed-by:
Daniel Wagner <dwagner@suse.de> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
-
Tyrel Datwyler authored
During MQ enablement of the ibmvfc driver ibmvfc_wait_for_ops() was missed. This function is responsible for waiting on commands to complete that match a certain criteria such as LUN or cancel key. The implementation as is only scans the CRQ for events ignoring any sub-queues and as a result will exit successfully without doing anything when operating in MQ channelized mode. Check the MQ and channel use flags to determine which queues are applicable, and scan each queue accordingly. Note in MQ mode SCSI commands are only issued down sub-queues and the CRQ is only used for driver specific management commands. As such the CRQ events are ignored when operating in MQ mode with channels. Link: https://lore.kernel.org/r/20210319205029.312969-3-tyreld@linux.ibm.com Fixes: 9000cb99 ("scsi: ibmvfc: Enable MQ and set reasonable defaults") Reviewed-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
-
Tyrel Datwyler authored
For various EH activities the ibmvfc driver uses ibmvfc_wait_for_ops() to wait for the completion of commands that match a given criteria be it cancel key, or specific LUN. With recent changes commands are completed outside the lock in bulk by removing them from the sent list and adding them to a private completion list. This introduces a potential race in ibmvfc_wait_for_ops() since the criteria for a command to be outstanding is no longer simply being on the sent list, but instead not being on the free list. Avoid this race by scanning the entire command event pool and checking that any matching command that ibmvfc needs to wait on is not already on the free list. Link: https://lore.kernel.org/r/20210319205029.312969-2-tyreld@linux.ibm.com Fixes: 1f4a4a19 ("scsi: ibmvfc: Complete commands outside the host/queue lock") Reviewed-by:
-
- 17 Mar, 2021 3 commits
-
-
Christophe JAILLET authored
mpt3sas_get_port_by_id() can be called when a spinlock is held. Use GFP_ATOMIC instead of GFP_KERNEL when allocating memory. Issue spotted by call_kern.cocci: ./drivers/scsi/mpt3sas/mpt3sas_scsih.c:416:42-52: ERROR: function mpt3sas_get_port_by_id called on line 7125 inside lock on line 7123 but uses GFP_KERNEL ./drivers/scsi/mpt3sas/mpt3sas_scsih.c:416:42-52: ERROR: function mpt3sas_get_port_by_id called on line 6842 inside lock on line 6839 but uses GFP_KERNEL ./drivers/scsi/mpt3sas/mpt3sas_scsih.c:416:42-52: ERROR: function mpt3sas_get_port_by_id called on line 6854 inside lock on line 6851 but uses GFP_KERNEL ./drivers/scsi/mpt3sas/mpt3sas_scsih.c:416:42-52: ERROR: function mpt3sas_get_port_by_id called on line 7706 inside lock on line 7702 but uses GFP_KERNEL ./drivers/scsi/mpt3sas/mpt3sas_scsih.c:416:42-52: ERROR: function mpt3sas_get_port_by_id called on line 10260 inside lock on line 10256 but uses GFP_KERNEL Link: https://lore.kernel.org/r/20210220093951.905362-1-christophe.jaillet@wanadoo.fr Fixes: 324c122f ("scsi: mpt3sas: Add module parameter multipath_on_hba") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
dongjian authored
The "lpm" and "->enabled" are all boolean. We should be using && rather than the bit operator. Link: https://lore.kernel.org/r/1615896915-148864-1-git-send-email-dj0227@163.com Fixes: 488edafb ("scsi: ufs-mediatek: Introduce low-power mode for device power supply") Reviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
dongjian <dongjian@yulong.com> Signed-off-by:
Yue Hu <huyue2@yulong.com> Signed-off-by:
-
Johannes Thumshirn authored
Recent changes changed the completion of SCSI commands from Soft-IRQ context to IRQ context. This triggers the following warning, when we're completing writes to zoned block devices that go through the zone append emulation: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc2+ #2 Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015 RIP: 0010:__local_bh_disable_ip+0x3f/0x50 RSP: 0018:ffff8883e1409ba8 EFLAGS: 00010006 RAX: 0000000080010001 RBX: 0000000000000001 RCX: 0000000000000013 RDX: ffff888129e4d200 RSI: 0000000000000201 RDI: ffffffff915b9dbd RBP: ffff888113e9a540 R08: ffff888113e9a540 R09: 00000000000077f0 R10: 0000000000080000 R11: 0000000000000001 R12: ffff888129e4d200 R13: 0000000000001000 R14: 00000000000077f0 R15: ffff888129e4d218 FS: 0000000000000000(0000) GS:ffff8883e1400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f8418ebc0 CR3: 000000021202a006 CR4: 00000000001706f0 Call Trace: <IRQ> _raw_spin_lock_bh+0x18/0x40 sd_zbc_complete+0x43d/0x1150 sd_done+0x631/0x1040 ? mark_lock+0xe4/0x2fd0 ? provisioning_mode_store+0x3f0/0x3f0 scsi_finish_command+0x31b/0x5c0 _scsih_io_done+0x960/0x29e0 [mpt3sas] ? mpt3sas_scsih_scsi_lookup_get+0x1c7/0x340 [mpt3sas] ? __lock_acquire+0x166b/0x58b0 ? _get_st_from_smid+0x4a/0x80 [mpt3sas] _base_process_reply_queue+0x23f/0x26e0 [mpt3sas] ? lock_is_held_type+0x98/0x110 ? find_held_lock+0x2c/0x110 ? mpt3sas_base_sync_reply_irqs+0x360/0x360 [mpt3sas] _base_interrupt+0x8d/0xd0 [mpt3sas] ? rcu_read_lock_sched_held+0x3f/0x70 __handle_irq_event_percpu+0x24d/0x600 handle_irq_event+0xef/0x240 ? handle_irq_event_percpu+0x110/0x110 handle_edge_irq+0x1f6/0xb60 __common_interrupt+0x75/0x160 common_interrupt+0x7b/0xa0 </IRQ> asm_common_interrupt+0x1e/0x40 Don't use spin_lock_bh() to protect the update of the write pointer offset cache, but use spin_lock_irqsave() for it. Link: https://lore.kernel.org/r/3cfebe48d09db73041b7849be71ffbcec7ee40b3.1615369586.git.johannes.thumshirn@wdc.com Fixes: 664f0dce ("scsi: mpt3sas: Add support for shared host tagset for CPU hotplug") Reported-by:
Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> Tested-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
-
- 16 Mar, 2021 5 commits
-
-
Dan Carpenter authored
If copy_from_user() or kstrtoull() fail then the correct behavior is to return a negative error code. Link: https://lore.kernel.org/r/YEsbU/UxYypVrC7/@mwanda Fixes: f9bb2da1 ("[SCSI] lpfc 8.3.27: T10 additions for SLI4") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Alexey Dobriyan authored
Only half of the file is under include guard because terminating #endif is placed too early. Link: https://lore.kernel.org/r/YE4snvoW1SuwcXAn@localhost.localdomainReviewed-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Lv Yunlong authored
In st_open(), if STp->in_use is true, STp will be freed by scsi_tape_put(). However, STp is still used by DEBC_printk() after. It is better to DEBC_printk() before scsi_tape_put(). Link: https://lore.kernel.org/r/20210311064636.10522-1-lyl2019@mail.ustc.edu.cnAcked-by:
Kai Mäkisara <kai.makisara@kolumbus.fi> Signed-off-by:
Lv Yunlong <lyl2019@mail.ustc.edu.cn> Signed-off-by:
-
Lv Yunlong authored
In myrs_cleanup(), cs->mmio_base will be freed twice by iounmap(). Link: https://lore.kernel.org/r/20210311063005.9963-1-lyl2019@mail.ustc.edu.cn Fixes: 77266186 ("scsi: myrs: Add Mylex RAID controller (SCSI interface)") Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Tyrel Datwyler authored
The buffer for negotiating channel setup is DMA allocated at device probe time. However, the remove path fails to free this allocation which will prevent the hypervisor from releasing the virtual device in the case of a hotplug remove. Fix this issue by freeing the buffer allocation in ibmvfc_free_mem(). Link: https://lore.kernel.org/r/20210311012212.428068-1-tyreld@linux.ibm.com Fixes: e95eef3f ("scsi: ibmvfc: Implement channel enquiry and setup commands") Signed-off-by:
-
- 04 Mar, 2021 10 commits
-
-
Vishal Bhakta authored
The entries in the source files are removed as well. Link: https://lore.kernel.org/r/20210226234347.21535-1-vbhakta@vmware.comSigned-off-by:
Vishal Bhakta <vbhakta@vmware.com> Signed-off-by:
-
Jiapeng Chong authored
Fix the following coccicheck warning: ./drivers/scsi/ufs/ufshcd.c:1538:8-16: WARNING: use scnprintf or sprintf. Link: https://lore.kernel.org/r/1614665298-115183-1-git-send-email-jiapeng.chong@linux.alibaba.comReported-by:
Abaci Robot <abaci@linux.alibaba.com> Reviewed-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Can Guo authored
Runtime and system suspend/resume can only come after hba probe invokes platform_set_drvdata(pdev, hba), meaning hba cannot be NULL in these PM callbacks, so remove the checks of !hba. Link: https://lore.kernel.org/r/1614145010-36079-4-git-send-email-cang@codeaurora.orgReviewed-by:
-
Nitin Rawat authored
Disable interrupt in reset path to flush pending IRQ handler in order to avoid possible NoC issues. Link: https://lore.kernel.org/r/1614145010-36079-3-git-send-email-cang@codeaurora.orgReviewed-by:
Nitin Rawat <nitirawa@codeaurora.org> Signed-off-by:
-
Can Guo authored
In error handling prepare stage, after SCSI requests are blocked, do a down/up_write(clk_scaling_lock) to clean up the queuecommand() path. Meanwhile, stop eeh_work in case it disturbs error recovery. Moreover, reset ufshcd_state at the entrance of ufshcd_probe_hba(), since it may be called multiple times during error recovery. Link: https://lore.kernel.org/r/1614145010-36079-2-git-send-email-cang@codeaurora.orgReviewed-by:
-
Tyrel Datwyler authored
A live partition migration (LPM) results in a CRQ disconnect similar to a hard reset. In this LPM case the hypervisor mostly preserves the CRQ transport such that it simply needs to be reenabled. However, the capabilities may have changed such as fewer channels, or no channels at all. Further, its possible that there may be sub-CRQ support, but no channel support. The CRQ reenable path currently doesn't take any of this into consideration. For simplicity release and reinitialize sub-CRQs during reenable, and set do_enquiry and using_channels with the appropriate values to trigger channel renegotiation. Link: https://lore.kernel.org/r/20210302230543.9905-6-tyreld@linux.ibm.com Fixes: 3034ebe2 ("scsi: ibmvfc: Add alloc/dealloc routines for SCSI Sub-CRQ Channels") Reviewed-by:
Brian King <brking@linux.ibm.com> Signed-off-by:
-
Tyrel Datwyler authored
The H_FREE_SUB_CRQ hypercall can return a retry delay return code that indicates the call needs to be retried after a specific amount of time delay. The error path to free a sub-CRQ in case of a failure during channel registration fails to capture the return code of H_FREE_SUB_CRQ which will result in the delay loop being skipped in the case of a retry delay return code. Store the return code result of the H_FREE_SUB_CRQ call such that the return code check in the delay loop evaluates a meaningful value. Also, use the rtas_busy_delay() to check the rc value and delay for the appropriate amount of time. Link: https://lore.kernel.org/r/20210302230543.9905-5-tyreld@linux.ibm.com Fixes: 39e461fd ("scsi: ibmvfc: Map/request irq and register Sub-CRQ interrupt handler") Reviewed-by:
-
Tyrel Datwyler authored
A non-zero return code for H_REG_SUB_CRQ is currently treated as a failure resulting in failing sub-CRQ setup. The case of H_CLOSED should not be treated as a failure. This return code translates to a successful sub-CRQ registration by the hypervisor, and is meant to communicate back that there is currently no partner VIOS CRQ connection established as of yet. This is a common occurrence during a disconnect where the client adapter can possibly come back up prior to the partner adapter. For non-zero return code from H_REG_SUB_CRQ treat a H_CLOSED as success so that sub-CRQs are successfully setup. Link: https://lore.kernel.org/r/20210302230543.9905-4-tyreld@linux.ibm.com Fixes: 3034ebe2 ("scsi: ibmvfc: Add alloc/dealloc routines for SCSI Sub-CRQ Channels") Reviewed-by:
-
Tyrel Datwyler authored
A hard reset results in a complete transport disconnect such that the CRQ connection with the partner VIOS is broken. This has the side effect of also invalidating the associated sub-CRQs. The current code assumes that the sub-CRQs are perserved resulting in a protocol violation after trying to reconnect them with the VIOS. This introduces an infinite loop such that the VIOS forces a disconnect after each subsequent attempt to re-register with invalid handles. Avoid the aforementioned issue by releasing the sub-CRQs prior to CRQ disconnect, and driving a reinitialization of the sub-CRQs once a new CRQ is registered with the hypervisor. Link: https://lore.kernel.org/r/20210302230543.9905-3-tyreld@linux.ibm.com Fixes: 3034ebe2 ("scsi: ibmvfc: Add alloc/dealloc routines for SCSI Sub-CRQ Channels") Reviewed-by:
-
Tyrel Datwyler authored
If ibmvfc_init_sub_crqs() fails ibmvfc_probe() simply parrots registration failure reported elsewhere, and futher vhost->scsi_scrq.scrq == NULL is indication enough to the driver that it has no sub-CRQs available. The mq_enabled check can also be moved into ibmvfc_init_sub_crqs() such that each caller doesn't have to gate the call with a mq_enabled check. Finally, in the case of sub-CRQ setup failure setting do_enquiry can be turned off to putting the driver into single queue fallback mode. The aforementioned changes also simplify the next patch in the series that fixes a hard reset issue, by tying a sub-CRQ setup failure and do_enquiry logic into ibmvfc_init_sub_crqs(). Link: https://lore.kernel.org/r/20210302230543.9905-2-tyreld@linux.ibm.comReviewed-by:
-
- 03 Mar, 2021 3 commits
-
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull misc fixes from Jens Axboe: "Two misc fixes that don't belong in other branches: - Fix a regression with ia64 signals, introduced by the TIF_NOTIFY_SIGNAL change in 5.11. - Fix the current swapfile regression from this merge window" * tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block: swap: fix swapfile read/write offset ia64: don't call handle_signal() unless there's actually a signal queued -
Jens Axboe authored
We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be... Fixes: 48d15436 ("mm: remove get_swap_bio") Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Jens Axboe authored
Sergei and John both reported that ia64 failed to boot in 5.11, and it was related to signals. Turns out the ia64 signal handling is a bit odd, it doesn't check the return value of get_signal() for whether there's a signal to deliver or not. With the introduction of TIF_NOTIFY_SIGNAL, then task_work could trigger it. Fix it by only calling handle_signal() if we actually have a real signal to deliver. This brings it in line with all other archs, too. Fixes: b269c229 ("ia64: add support for TIF_NOTIFY_SIGNAL") Reported-by:
Sergei Trofimovich <slyich@gmail.com> Reported-by:
-
- 01 Mar, 2021 3 commits
-
-
Linus Torvalds authored
Merge branch 'kmap-conversion-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull kmap conversion updates from David Sterba: "This contains changes regarding kmap API use and eg conversion from kmap_atomic to kmap_local_page. The API belongs to memory management but to save cross-tree dependency headaches we've agreed to take it through the btrfs tree because there are some trivial conversions possible, while the rest will need some time and getting the easy cases out of the way would be convenient. The changes can be grouped: - function exports, new helpers - new VM_BUG_ON for additional verification; it's been discussed if it should be VM_BUG_ON or BUG_ON, the former was chosen due to performance reasons - code replaced by relevant helpers" [ This is an updated version of a request that originally came in during the merge window, but I asked for some updates: https://lore.kernel.org/lkml/cover.1614090658.git.dsterba@suse.com/ which is why this got merge after the merge window closed. - Linus ] * 'kmap-conversion-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: use copy_highpage() instead of 2 kmaps() btrfs: use memcpy_[to|from]_page() and kmap_local_page() mm/highmem: Add VM_BUG_ON() to mem*_page() calls mm/highmem: Introduce memcpy_page(), memmove_page(), and memset_page() mm/highmem: Convert memcpy_[to|from]_page() to kmap_local_page() mm/highmem: Lift memcpy_[to|from]_page to core
-
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linuxLinus Torvalds authored
Pull btrfs fixes from David Sterba: "This is the first batch of fixes that usually arrive during the merge window code freeze. Regressions and stable material. Regressions: - fix deadlock in log sync in zoned mode - fix bugs in subpage mode still wrongly assuming sectorsize == page size Fixes: - fix missing kunmap of the Q stripe in RAID6 - block group fixes: - fix race between extent freeing/allocation when using bitmaps - avoid double put of block group when emptying cluster - swapfile fixes: - fix swapfile writes vs running scrub - fix swapfile activation vs snapshot creation - fix stale data exposure after cloning a hole with NO_HOLES enabled - remove tree-checker check that does not work in case information from other leaves is necessary" * tag 'for-5.12-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: zoned: fix deadlock on log sync btrfs: avoid double put of block group when emptying cluster btrfs: fix stale data exposure after cloning a hole with NO_HOLES enabled btrfs: tree-checker: do not error out if extent ref hash doesn't match btrfs: fix race between swap file activation and snapshot creation btrfs: fix race between writes to swap files and scrub btrfs: avoid checking for RO block group twice during nocow writeback btrfs: fix race between extent freeing/allocation when using bitmaps btrfs: make check_compressed_csum() to be subpage compatible btrfs: make btrfs_submit_compressed_read() subpage compatible btrfs: fix raid6 qstripe kmap -
Linus Torvalds authored
-
- 28 Feb, 2021 1 commit
-
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull ide fix from Jens Axboe: "This is a leftover fix from 5.11, where I forgot to ship it your way" * tag 'ide-5.11-2021-02-28' of git://git.kernel.dk/linux-block: ide/falconide: Fix module unload
-
