Target de-configuration panics at high CPU load because TPGT and WWPN can
be removed on separate threads.
TPGT removal requests a reset HBA on a separate thread and waits for reset
complete (phase1). Due to high CPU load that HBA reset can be delayed for
some time.
WWPN removal does qlt_stop_phase2(). There it is believed that phase1 has
already completed and thus tgt.tgt_ops is subsequently cleared. However,
tgt.tgt_ops is needed to process incoming traffic and therefore this will
cause one of the following panics:
NIP qlt_reset+0x7c/0x220 [qla2xxx]
LR qlt_reset+0x68/0x220 [qla2xxx]
Call Trace:
0xc000003ffff63a78 (unreliable)
qlt_handle_imm_notify+0x800/0x10c0 [qla2xxx]
qlt_24xx_atio_pkt+0x208/0x590 [qla2xxx]
qlt_24xx_process_atio_queue+0x33c/0x7a0 [qla2xxx]
qla83xx_msix_atio_q+0x54/0x90 [qla2xxx]
or
NIP qlt_24xx_handle_abts+0xd0/0x2a0 [qla2xxx]
LR qlt_24xx_handle_abts+0xb4/0x2a0 [qla2xxx]
Call Trace:
qlt_24xx_handle_abts+0x90/0x2a0 [qla2xxx] (unreliable)
qlt_24xx_process_atio_queue+0x500/0x7a0 [qla2xxx]
qla83xx_msix_atio_q+0x54/0x90 [qla2xxx]
or
NIP qlt_create_sess+0x90/0x4e0 [qla2xxx]
LR qla24xx_do_nack_work+0xa8/0x180 [qla2xxx]
Call Trace:
0xc0000000348fba30 (unreliable)
qla24xx_do_nack_work+0xa8/0x180 [qla2xxx]
qla2x00_do_work+0x674/0xbf0 [qla2xxx]
qla2x00_iocb_work_fn
The patch fixes the issue by serializing qlt_stop_phase1() and
qlt_stop_phase2() functions to make WWPN removal wait for phase1
completion.
Link: https://lore.kernel.org/r/20210415203554.27890-1-d.bogdanov@yadro.com
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
[ commit 2ef7665dfd88830f15415ba007c7c9a46be7acd8 upstream ]
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9517 d57e44dd-8a1f-0410-8b47-8ef2f437770f
The status_byte() macro and also the SAM_STAT_* macros shifted right by one
bit have been removed from kernel v5.14. Hence open-code status_byte() and
change GOOD into SAM_STAT_GOOD etc.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9505 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This patch fixes a bug by changing SAM_STAT_CHECK_CONDITION << 1 into
SAM_STAT_CHECK_CONDITION in the SCSI result code.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9502 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This patch prevents that a compiler warning is reported when building this
driver against kernel v5.14.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9500 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Use the proper error codes when reporting a BSG error. The DID_* codes are
the codes that are shifted left 16 bits while the DRIVER_* codes must be
shifted left 24 bits.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9499 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Remove the invocation of the 'which' command since that command has been
deprecated in Debian 11 and since I am not aware of any other portable
approach for querying the path of a command.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9494 d57e44dd-8a1f-0410-8b47-8ef2f437770f
The code for removing weak updates did not fix the reported issue.
Additionally, that code can remove weak updates that are not related to
SCST. Hence remove the code again that removes weak updates.
Reported-by: Tu, Rongqing <rongqing.tu@hpe.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9493 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Only check whether a LUN has already been registered with the copy manager
for the auto_cm_assignment=1 case since with auto CM assignment disabled
scst_cm_dev_register() is called after the LUN has been registered.
Reported-by: Eitan Cohen <eitancohen456@gmail.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9492 d57e44dd-8a1f-0410-8b47-8ef2f437770f
The INQUIRY command sent by the copy manager can only succeed if the LUN it
is submitted to exists before the INQUIRY command is sent. Hence this patch
that swaps the order of the scst_cm_on_add_lun() and scst_alloc_add_tgt_dev()
calls in scst_acg_add_lun(). This patch prevents that the INQUIRY commands
submitted by the copy manager fail as follows:
Not supported dev type 7f, ignoring
Reported-by: Eitan Cohen <eitancohen456@gmail.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9491 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Move PRINT_ERROR to the body of RDMA_CM_EVENT_CONNECT_REQUET because only
it can return an error and not log information about it.
Signed-off-by: Chesnokov Gleb <Chesnokov.G@raidix.com>
[bvanassche: modified patch title]
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9486 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Since `make_path` is called in pretty much any interaction with sysfs,
speed degradation in it has visible impact when plenty of resources
being managed. So much that it reaches the same great execution time as
calls to filesystem, such as `-d`.
Reported-by: Dyadyushkin Aleksandr <dyadyushkin.a@raidix.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9485 d57e44dd-8a1f-0410-8b47-8ef2f437770f
During processing RDMA_CM_EVENT_ADDR_CHANGE event rdma_bind_addr in isert_setup_id function from isert_cm_evt_listener_handler returns error -98 [EADDRINUSE].
In principle, it is logical, because at that time the socket address was still bound to the old cma_id which will be destroyed via rdma_destroy_id only after processing the RDMA_CM_EVENT_ADDR_CHANGE event.
Move the creation of the cma_id in workqueue context and delete old cma_id directly, not through returning the error code to the upper level.
Signed-off-by: Chesnokov Gleb <Chesnokov.G@raidix.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9484 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Introduce the function isert_setup_id(). This function creates and sets up
an RDMA CM ID. Move the isert_portal_listen() call into isert_portal_create().
Signed-off-by: Chesnokov Gleb <Chesnokov.G@raidix.com>
[ bvanassche: edited patch description and dropped support for older kernel
versions in the PRINT_INFO() statement ]
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9481 d57e44dd-8a1f-0410-8b47-8ef2f437770f
When the low level driver exercises the hot unplug they would call
rdma_cm cma_remove_one which would fire DEVICE_REMOVAL event to all cma
consumers. Now, if consumer doesn't make sure they destroy all IB
objects created on that IB device instance prior to finalizing all
processing of DEVICE_REMOVAL callback, rdma_cm will let the lld to
de-register with IB core and destroy the IB device instance. And if the
consumer calls (say) ib_dereg_mr(), it will crash since that dev object
is NULL.
In the current implementation, iser-target just initiates the cleanup
and returns from DEVICE_REMOVAL callback. This deferred work creates a
race between iser-target cleaning IB objects(say MR) and lld destroying
IB device instance.
This patch includes the following fixes
-> make sure that consumer frees all IB objects associated with device
instance
-> return non-zero from the callback to destroy the rdma_cm id
Signed-off-by: Raju Rangoju <rajur@chelsio.com>
Acked-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Doug Ledford <dledford@redhat.com>
See also upstream commit 63b268d232b8 ("IB/isert: Properly release
resources on DEVICE_REMOVAL")
Signed-off-by: Chesnokov Gleb <Chesnokov.G@raidix.com>
[ bvanassche: edited patch description and moved a break statement into a code
block ]
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9480 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Minimize the diffs with the upstream code base by introducing the function
isert_conn_init().
Signed-off-by: Chesnokov Gleb <Chesnokov.G@raidix.com>
[ bvanassche: edited patch description ]
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9478 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Move the isert_cm_disconnect_handler() definition, pass the event type to
isert_cm_evt_listener_handler() instead of the struct rdma_cm_event pointer
and change the return value of isert_cm_evt_listener_handler() from 0 /
-EINVAL into -1.
Signed-off-by: Chesnokov Gleb <Chesnokov.G@raidix.com>
[ bvanassche: made the patch description more detailed ]
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@9473 d57e44dd-8a1f-0410-8b47-8ef2f437770f
