- 02 Jun, 2021 40 commits
-
-
Mike Christie authored
Drivers shouldn't be calling block/unblock session for cmd cleanup because the functions can change the session state from under libiscsi. This adds a new a driver level bit so it can block all I/O the host while it drains the card. Link: https://lore.kernel.org/r/20210525181821.7617-26-michael.christie@oracle.comReviewed-by:
Manish Rangankar <mrangankar@marvell.com> Signed-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Mike Christie authored
Drivers shouldn't be calling block/unblock session for tmf handling because the functions can change the session state from under libiscsi. iscsi_queuecommand's call to iscsi_prep_scsi_cmd_pdu-> iscsi_check_tmf_restrictions will prevent new cmds from being sent to qedi after we've started handling a TMF. So we don't need to try and block it in the driver, and we can remove these block calls. Link: https://lore.kernel.org/r/20210525181821.7617-25-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
We run from a workqueue with no locks held so use GFP_NOIO. Link: https://lore.kernel.org/r/20210525181821.7617-24-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
qedi_iscsi_abort_work and qedi_tmf_work both allocate a tid then call qedi_send_iscsi_tmf which also allocates a tid. This removes the tid allocation from the callers. Link: https://lore.kernel.org/r/20210525181821.7617-23-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If qedi_tmf_work's qedi_wait_for_cleanup_request call times out we will also force the clean up of the qedi_work_map but qedi_process_cmd_cleanup_resp could still be accessing the qedi_cmd. To fix this issue we extend where we hold the tmf_work_lock and back_lock so the qedi_process_cmd_cleanup_resp access is serialized with the cleanup done in qedi_tmf_work and any completion handling for the iscsi_task. Link: https://lore.kernel.org/r/20210525181821.7617-22-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If the SCSI cmd completes after qedi_tmf_work calls iscsi_itt_to_task then the qedi qedi_cmd->task_id could be freed and used for another cmd. If we then call qedi_iscsi_cleanup_task with that task_id we will be cleaning up the wrong cmd. Wait to release the task_id until the last put has been done on the iscsi_task. Because libiscsi grabs a ref to the task when sending the abort, we know that for the non-abort timeout case that the task_id we are referencing is for the cmd that was supposed to be aborted. A latter commit will fix the case where the abort times out while we are running qedi_tmf_work. Link: https://lore.kernel.org/r/20210525181821.7617-21-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If qedi_process_cmd_cleanup_resp finds the cmd it frees the work and sets list_tmf_work to NULL, so qedi_tmf_work should check if list_tmf_work is non-NULL when it wants to force cleanup. Link: https://lore.kernel.org/r/20210525181821.7617-20-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
This doesn't fix any bugs, but it makes more sense to free the pool after we have removed the session. At that time we know nothing is touching any of the session fields, because all devices have been removed and scans are stopped. Link: https://lore.kernel.org/r/20210525181821.7617-19-michael.christie@oracle.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
-
Mike Christie authored
For aborts, qedi needs to cleanup the FW then send the TMF from a worker thread. While it's doing these the cmd could complete normally and the TMF could time out. libiscsi would then complete the iscsi_task which will call into the driver to cleanup the driver level resources while it still might be accessing them for the cleanup/abort. This has iscsi_eh_abort keep the iscsi_task ref if the TMF times out, so qedi does not have to worry about if the task is being freed while in use and does not need to get its own ref. Link: https://lore.kernel.org/r/20210525181821.7617-18-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
We set the max_active iSCSI EH works to 1, so all work is going to execute in order by default. However, userspace can now override this in sysfs. If max_active > 1, we can end up with the block_work on CPU1 and iscsi_unblock_session running the unblock_work on CPU2 and the session and target/device state will end up out of sync with each other. This adds a flush of the block_work in iscsi_unblock_session. Link: https://lore.kernel.org/r/20210525181821.7617-17-michael.christie@oracle.com Fixes: 1d726aa6 ("scsi: iscsi: Optimize work queue flush use") Reviewed-by:
-
Mike Christie authored
We have a ref to the task being aborted, so SCp.ptr will never be NULL. We need to use iscsi_task_is_completed to check for the completed state. Link: https://lore.kernel.org/r/20210525181821.7617-16-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
The iscsi offload drivers are setting the shost->max_id to the max number of sessions they support. The problem is that max_id is not the max number of targets but the highest identifier the targets can have. To use it to limit the number of targets we need to set it to max sessions - 1, or we can end up with a session we might not have preallocated resources for. Link: https://lore.kernel.org/r/20210525181821.7617-15-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If we haven't done a unbind target call we can race where iscsi_conn_teardown wakes up the EH thread and then frees the conn while those threads are still accessing the conn ehwait. We can only do one TMF per session so this just moves the TMF fields from the conn to the session. We can then rely on the iscsi_session_teardown->iscsi_remove_session->__iscsi_unbind_session call to remove the target and it's devices, and know after that point there is no device or scsi-ml callout trying to access the session. Link: https://lore.kernel.org/r/20210525181821.7617-14-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
The comment in iscsi_eh_session_reset is wrong and we don't wait for the EH to complete before tearing down the conn. This has us get a ref to the conn when we are not holding the eh_mutex/frwd_lock so it does not get freed from under us. Link: https://lore.kernel.org/r/20210525181821.7617-13-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
If SCSI midlayer is aborting a task when we are tearing down the conn we could free the conn while the abort thread is accessing the conn. This has the abort handler get a ref to the conn so it won't be freed from under it. Note: this is not needed for device/target reset because we are holding the eh_mutex when accessing the conn. Link: https://lore.kernel.org/r/20210525181821.7617-12-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
There are a couple places where we could free the iscsi_cls_conn while it's still in use. This adds some helpers to get/put a refcount on the struct and converts an exiting user. Subsequent commits will then use the helpers to fix 2 bugs in the eh code. Link: https://lore.kernel.org/r/20210525181821.7617-11-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Make sure the conn socket shutdown starts before we start the timer to fail commands to upper layers. Link: https://lore.kernel.org/r/20210525181821.7617-10-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Userspace (open-iscsi based tools at least) sets no linger on the socket to prevent stale data from being sent. However, with the in-kernel cleanup if userspace is not up the sockfd_put will release the socket without having set that sockopt. iscsid sets that opt at socket close time, but it seems ok to set this at setup time in the kernel for all tools. Link: https://lore.kernel.org/r/20210525181821.7617-9-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Commit 0ab71045 ("scsi: iscsi: Perform connection failure entirely in kernel space") has the following regressions/bugs that this patch fixes: 1. It can return cmds to upper layers like dm-multipath where that can retry them. After they are successful the fs/app can send new I/O to the same sectors, but we've left the cmds running in FW or in the net layer. We need to be calling ep_disconnect if userspace is not up. This patch only fixes the issue for offload drivers. iscsi_tcp will be fixed in separate commit because it doesn't have a ep_disconnect call. 2. The drivers that implement ep_disconnect expect that it's called before conn_stop. Besides crashes, if the cleanup_task callout is called before ep_disconnect it might free up driver/card resources for session1 then they could be allocated for session2. But because the driver's ep_disconnect is not called it has not cleaned up the firmware so the card is still using the resources for the original cmd. 3. The stop_conn_work_fn can run after userspace has done its recovery and we are happily using the session. We will then end up with various bugs depending on what is going on at the time. We may also run stop_conn_work_fn late after userspace has called stop_conn and ep_disconnect and is now going to call start/bind conn. If stop_conn_work_fn runs after bind but before start, we would leave the conn in a unbound but sort of started state where IO might be allowed even though the drivers have been set in a state where they no longer expect I/O. 4. Returning -EAGAIN in iscsi_if_destroy_conn if we haven't yet run the in kernel stop_conn function is breaking userspace. We should have been doing this for the caller. Link: https://lore.kernel.org/r/20210525181821.7617-8-michael.christie@oracle.com Fixes: 0ab71045 ("scsi: iscsi: Perform connection failure entirely in kernel space") Reviewed-by:
-
Mike Christie authored
Subsequent commits allow the kernel to do ep_disconnect. In that case we will have to get a proper refcount on the ep so one thread does not delete it from under another. Link: https://lore.kernel.org/r/20210525181821.7617-7-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Use the system_unbound_wq for async session destruction. We don't need a dedicated workqueue for async session destruction because: 1. perf does not seem to be an issue since we only allow 1 active work. 2. it does not have deps with other system works and we can run them in parallel with each other. Link: https://lore.kernel.org/r/20210525181821.7617-6-michael.christie@oracle.comReviewed-by: -
Mike Christie authored
If the system is not up, we can just fail immediately since iscsid is not going to ever answer our netlink events. We are already setting the recovery_tmo to 0, but by passing stop_conn STOP_CONN_TERM we never will block the session and start the recovery timer, because for that flag userspace will do the unbind and destroy events which would remove the devices and wake up and kill the eh. Since the conn is dead and the system is going dowm this just has us use STOP_CONN_RECOVER with recovery_tmo=0 so we fail immediately. However, if the user has set the recovery_tmo=-1 we let the system hang like they requested since they might have used that setting for specific reasons (one known reason is for buggy cluster software). Link: https://lore.kernel.org/r/20210525181821.7617-5-michael.christie@oracle.comSigned-off-by:
-
Mike Christie authored
libiscsi will now suspend the send/tx queue for the drivers so we can drop it from the drivers ep_disconnect. Link: https://lore.kernel.org/r/20210525181821.7617-4-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
During ep_disconnect we have been doing iscsi_suspend_tx/queue to block new I/O but every driver except cxgbi and iscsi_tcp can still get I/O from __iscsi_conn_send_pdu() if we haven't called iscsi_conn_failure() before ep_disconnect. This could happen if we were terminating the session, and the logout timed out before it was even sent to libiscsi. Fix the issue by adding a helper which reverses the bind_conn call that allows new I/O to be queued. Drivers implementing ep_disconnect can use this to make sure new I/O is not queued to them when handling the disconnect. Link: https://lore.kernel.org/r/20210525181821.7617-3-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
This adds a helper to detect if a cmd has completed but is not yet freed. Link: https://lore.kernel.org/r/20210525181821.7617-2-michael.christie@oracle.comReviewed-by:
-
Chandrakanth Patil authored
Link: https://lore.kernel.org/r/20210528131307.25683-6-chandrakanth.patil@broadcom.comSigned-off-by:
Chandrakanth Patil <chandrakanth.patil@broadcom.com> Signed-off-by:
-
Chandrakanth Patil authored
While reenabling the IRQ after IRQ poll there may be a small window for the firmware to post the replies with interrupts raised. In that case the driver will not see the interrupts which leads to I/O timeout. This issue only happens when there are many I/O completions on a single reply queue. This forces the driver to switch between the interrupt and IRQ context. Make the driver process the reply queue one more time after enabling the IRQ. Link: https://lore.kernel.org/linux-scsi/20201102072746.27410-1-sreekanth.reddy@broadcom.com/ Link: https://lore.kernel.org/r/20210528131307.25683-5-chandrakanth.patil@broadcom.com Cc: Tomas Henzl <thenzl@redhat.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Kashyap Desai authored
Consider the case where a VD is deleted and the targetID of that VD is assigned to a newly created VD. If the sequence of deletion/addition of VD happens very quickly there is a possibility that second event (VD add) occurs even before the driver processes the first event (VD delete). As event processing is done in deferred context the device list remains the same (but targetID is re-used) so driver will not learn the VD deletion/additon. I/Os meant for the older VD will be directed to new VD which may lead to data corruption. Make driver detect the deleted VD as soon as possible based on the RaidMap update and block further I/O to that device. Link: https://lore.kernel.org/r/20210528131307.25683-4-chandrakanth.patil@broadcom.comReported-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
-
Chandrakanth Patil authored
The driver doesn't clean up all the allocated resources properly when scsi_add_host(), megasas_start_aen() function fails during the PCI device probe. Clean up all those resources. Link: https://lore.kernel.org/r/20210528131307.25683-3-chandrakanth.patil@broadcom.comSigned-off-by:
-
Chandrakanth Patil authored
The driver issues all non-ReadWrite I/Os for TYPE_ENCLOSURE devices through the fast path with invalid dev handle. Fast path in turn directs all the I/Os to the firmware. As firmware stopped handling those I/Os from SAS3.5 generation of controllers (Ventura generation and onwards) this will lead to I/O failures. Switch the driver to issue all the non-ReadWrite I/Os for TYPE_ENCLOSURE devices directly to firmware for SAS3.5 generation of controllers and later. Link: https://lore.kernel.org/r/20210528131307.25683-2-chandrakanth.patil@broadcom.com Cc: <stable@vger.kernel.org> # v5.11+ Signed-off-by:
-
Kashyap Desai authored
Link: https://lore.kernel.org/r/20210520152545.2710479-25-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
-
Kashyap Desai authored
Link: https://lore.kernel.org/r/20210520152545.2710479-24-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
Read PCI_EXT_CAP_ID_DSN to query security status. The driver will throw a warning message when a non-secure type controller is detected. The purpose of this interface is to avoid interacting with any firmware which is not secured/signed by Broadcom. Any tampering on firmware component will be detected by hardware and it will be communicated to the driver to avoid any further interaction with that component. Link: https://lore.kernel.org/r/20210520152545.2710479-23-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
Link: https://lore.kernel.org/r/20210520152545.2710479-22-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
Wait for host I/O completion (default 180 seconds) if I/O timeout is detected on VDs. Link: https://lore.kernel.org/r/20210520152545.2710479-21-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
Link: https://lore.kernel.org/r/20210520152545.2710479-20-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
Unlock the host diagnostic register, write the specific reset type to that and wait for reset acknowledgment from the controller. If the reset is not successful retry for the predefined number of times Link: https://lore.kernel.org/r/20210520152545.2710479-19-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
Register driver for threaded interrupts. By default the driver will attempt I/O completion from interrupt context (primary handler). Since the driver tracks per reply queue outstanding I/Os, it will schedule threaded ISR if there are any outstanding I/Os expected on that particular reply queue. Threaded ISR (secondary handler) will loop for I/O completion as long as there are outstanding I/Os (speculative method using same per reply queue outstanding counter) or it has completed some X amount of commands (something like budget). Link: https://lore.kernel.org/r/20210520152545.2710479-18-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
The controller hardware can not handle certain UNMAP commands for NVMe drives. Add support in the driver for checking those commands and handle them appropriately. Link: https://lore.kernel.org/r/20210520152545.2710479-17-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
Kashyap Desai authored
Instead of driver returning DID_NO_CONNECT during driver unload allow SSU and Sync Cache commands to be sent to the controller to flush any cached data from the drive. Link: https://lore.kernel.org/r/20210520152545.2710479-16-kashyap.desai@broadcom.com Cc: sathya.prakash@broadcom.com Reviewed-by:
-
