Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21 |
|
#
673db054 |
| 18-Mar-2023 |
Mike Christie <michael.christie@oracle.com> |
scsi: target: Fix multiple LUN_RESET handling
This fixes a bug where an initiator thinks a LUN_RESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target
scsi: target: Fix multiple LUN_RESET handling
This fixes a bug where an initiator thinks a LUN_RESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target: Delete tmr from list before processing").
The problem occurs when:
1. We have N I/O cmds running in the target layer spread over 2 sessions.
2. The initiator sends a LUN_RESET for each session.
3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list.
4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists.
5. sessions2's LUN_RESET will then complete with a successful response.
6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them.
7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already.
Fix the bug by reverting the patch, and serialize the execution of LUN_RESETs and Preempt and Aborts.
Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list, because it turns out the original patch fixed a bug that was not mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second LUN_RESET and wait on it. Then the second reset will run core_tmr_drain_tmr_list and see the first reset and wait on it resulting in a deadlock.
Fixes: 51ec502a3266 ("target: Delete tmr from list before processing") Signed-off-by: Mike Christie <michael.christie@oracle.com> Link: https://lore.kernel.org/r/20230319015620.96006-8-michael.christie@oracle.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19 |
|
#
84ed64b1 |
| 10-Jan-2023 |
Maurizio Lombardi <mlombard@redhat.com> |
scsi: target: core: Fix warning on RT kernels
Calling spin_lock_irqsave() does not disable the interrupts on realtime kernels, remove the warning and replace assert_spin_locked() with lockdep_assert
scsi: target: core: Fix warning on RT kernels
Calling spin_lock_irqsave() does not disable the interrupts on realtime kernels, remove the warning and replace assert_spin_locked() with lockdep_assert_held().
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230110125310.55884-1-mlombard@redhat.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14 |
|
#
12b6fcd0 |
| 18-Oct-2021 |
Dmitry Bogdanov <d.bogdanov@yadro.com> |
scsi: target: core: Remove from tmr_list during LUN unlink
Currently TMF commands are removed from de_device.dev_tmf_list at the very end of se_cmd lifecycle. However, se_lun unlinks from se_cmd upo
scsi: target: core: Remove from tmr_list during LUN unlink
Currently TMF commands are removed from de_device.dev_tmf_list at the very end of se_cmd lifecycle. However, se_lun unlinks from se_cmd upon a command status (response) being queued in transport layer. This means that LUN and backend device can be deleted in the meantime and a panic will occur:
target_tmr_work() cmd->se_tfo->queue_tm_rsp(cmd); // send abort_rsp to a wire transport_lun_remove_cmd(cmd) // unlink se_cmd from se_lun - // - // - // - <<<--- lun remove <<<--- core backend device remove - // - // - // - qlt_handle_abts_completion() tfo->free_mcmd() transport_generic_free_cmd() target_put_sess_cmd() core_tmr_release_req() { if (dev) { // backend device, can not be null spin_lock_irqsave(&dev->se_tmr_lock, flags); //<<<--- CRASH
Call Trace: NIP [c000000000e1683c] _raw_spin_lock_irqsave+0x2c/0xc0 LR [c00800000e433338] core_tmr_release_req+0x40/0xa0 [target_core_mod] Call Trace: (unreliable) 0x0 target_put_sess_cmd+0x2a0/0x370 [target_core_mod] transport_generic_free_cmd+0x6c/0x1b0 [target_core_mod] tcm_qla2xxx_complete_mcmd+0x28/0x50 [tcm_qla2xxx] process_one_work+0x2c4/0x5c0 worker_thread+0x88/0x690
For the iSCSI protocol this is easily reproduced:
- Send some SCSI sommand
- Send Abort of that command over iSCSI
- Remove LUN on target
- Send next iSCSI command to acknowledge the Abort_Response
- Target panics
There is no need to keep the command in tmr_list until response completion, so move the removal from tmr_list from the response completion to the response queueing when the LUN is unlinked. Move the removal from state list too as it is a subject to the same race condition.
Link: https://lore.kernel.org/r/20211018135753.15297-1-d.bogdanov@yadro.com Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
#
b65e9044 |
| 18-Oct-2021 |
Dmitry Bogdanov <d.bogdanov@yadro.com> |
scsi: target: core: Remove from tmr_list during LUN unlink
[ Upstream commit 12b6fcd0ea7f3cb7c3b34668fc678779924123ae ]
Currently TMF commands are removed from de_device.dev_tmf_list at the very en
scsi: target: core: Remove from tmr_list during LUN unlink
[ Upstream commit 12b6fcd0ea7f3cb7c3b34668fc678779924123ae ]
Currently TMF commands are removed from de_device.dev_tmf_list at the very end of se_cmd lifecycle. However, se_lun unlinks from se_cmd upon a command status (response) being queued in transport layer. This means that LUN and backend device can be deleted in the meantime and a panic will occur:
target_tmr_work() cmd->se_tfo->queue_tm_rsp(cmd); // send abort_rsp to a wire transport_lun_remove_cmd(cmd) // unlink se_cmd from se_lun - // - // - // - <<<--- lun remove <<<--- core backend device remove - // - // - // - qlt_handle_abts_completion() tfo->free_mcmd() transport_generic_free_cmd() target_put_sess_cmd() core_tmr_release_req() { if (dev) { // backend device, can not be null spin_lock_irqsave(&dev->se_tmr_lock, flags); //<<<--- CRASH
Call Trace: NIP [c000000000e1683c] _raw_spin_lock_irqsave+0x2c/0xc0 LR [c00800000e433338] core_tmr_release_req+0x40/0xa0 [target_core_mod] Call Trace: (unreliable) 0x0 target_put_sess_cmd+0x2a0/0x370 [target_core_mod] transport_generic_free_cmd+0x6c/0x1b0 [target_core_mod] tcm_qla2xxx_complete_mcmd+0x28/0x50 [tcm_qla2xxx] process_one_work+0x2c4/0x5c0 worker_thread+0x88/0x690
For the iSCSI protocol this is easily reproduced:
- Send some SCSI sommand
- Send Abort of that command over iSCSI
- Remove LUN on target
- Send next iSCSI command to acknowledge the Abort_Response
- Target panics
There is no need to keep the command in tmr_list until response completion, so move the removal from tmr_list from the response completion to the response queueing when the LUN is unlinked. Move the removal from state list too as it is a subject to the same race condition.
Link: https://lore.kernel.org/r/20211018135753.15297-1-d.bogdanov@yadro.com Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20 |
|
#
3d75948b |
| 27-Feb-2021 |
Mike Christie <michael.christie@oracle.com> |
scsi: target: core: Flush submission work during TMR processing
If a cmd is on the submission workqueue then the TMR code will miss it, and end up returning task not found or success for LUN resets.
scsi: target: core: Flush submission work during TMR processing
If a cmd is on the submission workqueue then the TMR code will miss it, and end up returning task not found or success for LUN resets. The fabric driver might then tell the initiator that the running cmds have been handled when they are about to run.
This adds a flush when we are processing TMRs to make sure queued cmds do not run after returning the TMR response.
Link: https://lore.kernel.org/r/20210227170006.5077-25-michael.christie@oracle.com Tested-by: Laurence Oberman <loberman@redhat.com> Reviewed-by: Bodo Stroesser <bostroesser@gmail.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
1526d9f1 |
| 01-Nov-2020 |
Mike Christie <michael.christie@oracle.com> |
scsi: target: Make state_list per CPU
Do a state_list/execute_task_lock per CPU, so we can do submissions from different CPUs without contention with each other.
Note: tcm_fc was passing TARGET_SCF
scsi: target: Make state_list per CPU
Do a state_list/execute_task_lock per CPU, so we can do submissions from different CPUs without contention with each other.
Note: tcm_fc was passing TARGET_SCF_USE_CPUID, but never set cpuid. The assumption is that it wanted to set the cpuid to the CPU it was submitting from so it will get this behavior with this patch.
[mkp: s/printk/pr_err/ + resolve COMPARE AND WRITE patch conflict]
Link: https://lore.kernel.org/r/1604257174-4524-8-git-send-email-michael.christie@oracle.com Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54 |
|
#
2e45a1a9 |
| 26-Jul-2020 |
Bodo Stroesser <bstroesser@ts.fujitsu.com> |
scsi: target: Add tmr_notify backend function
Target core is modified to call an optional backend callback function if a TMR is received or commands are aborted implicitly after a PR command was rec
scsi: target: Add tmr_notify backend function
Target core is modified to call an optional backend callback function if a TMR is received or commands are aborted implicitly after a PR command was received. The backend function takes as parameters the se_dev, the type of the TMR, and the list of aborted commands. If no commands were aborted, an empty list is supplied.
Link: https://lore.kernel.org/r/20200726153510.13077-3-bstroesser@ts.fujitsu.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
#
f5e2714a |
| 26-Jul-2020 |
Bodo Stroesser <bstroesser@ts.fujitsu.com> |
scsi: target: Modify core_tmr_abort_task()
This patch modifies core_tmr_abort_task() to use same looping and locking scheme as core_tmr_drain_state_list() does.
This frees the state_list element in
scsi: target: Modify core_tmr_abort_task()
This patch modifies core_tmr_abort_task() to use same looping and locking scheme as core_tmr_drain_state_list() does.
This frees the state_list element in se_cmd for later use by tmr notification handling.
Note: __target_check_io_state() now is called with param 0 instead of dev->dev_attrib.emulate_tas, because tas is not relevant since we always get ABRT on same session like the aborted command.
Link: https://lore.kernel.org/r/20200726153510.13077-2-bstroesser@ts.fujitsu.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2 |
|
#
a36840d8 |
| 07-Jun-2020 |
Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com> |
scsi: target: Initialize LUN in transport_init_se_cmd()
Initialization of orig_fe_lun is moved to transport_init_se_cmd() from transport_lookup_cmd_lun(). This helps for the cases where the SCSI req
scsi: target: Initialize LUN in transport_init_se_cmd()
Initialization of orig_fe_lun is moved to transport_init_se_cmd() from transport_lookup_cmd_lun(). This helps for the cases where the SCSI request fails before the call to transport_lookup_cmd_lun() so that trace_target_cmd_complete() can print the LUN information to the trace buffer. Due to this change, the lun parameter is removed from transport_lookup_cmd_lun() and transport_lookup_tmr_lun().
Link: https://lore.kernel.org/r/1591559913-8388-3-git-send-email-sudhakar.panneerselvam@oracle.com Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21 |
|
#
87310c9f |
| 19-Feb-2020 |
David Disseldorp <ddiss@suse.de> |
scsi: target: convert boolean se_dev_attrib types to bool
This should harden us against configfs API regressions similar to the one fixed by the previous commit.
Link: https://marc.info/?l=target-d
scsi: target: convert boolean se_dev_attrib types to bool
This should harden us against configfs API regressions similar to the one fixed by the previous commit.
Link: https://marc.info/?l=target-devel&m=158211731505174 Signed-off-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
1a59d1b8 |
| 27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1334 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6 |
|
#
fae43461 |
| 02-Apr-2019 |
Bart Van Assche <bvanassche@acm.org> |
scsi: target/core: Rework the SPC-2 reservation handling code
Instead of tracking the initiator that established an SPC-2 reservation, track the session through which the SPC-2 reservation has been
scsi: target/core: Rework the SPC-2 reservation handling code
Instead of tracking the initiator that established an SPC-2 reservation, track the session through which the SPC-2 reservation has been established. This patch does not change any functionality.
Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18 |
|
#
2281c95f |
| 25-Jan-2019 |
Bart Van Assche <bvanassche@acm.org> |
scsi: target/core: Simplify the LUN RESET implementation
Due to the task management handling rework it is safe to wait for a TMF that is not in the active state. Hence remove the CMD_T_ACTIVE test f
scsi: target/core: Simplify the LUN RESET implementation
Due to the task management handling rework it is safe to wait for a TMF that is not in the active state. Hence remove the CMD_T_ACTIVE test from core_tmr_drain_tmr_list(). Additionally, call __target_check_io_state() instead of open coding it.
Reviewed-by: Hannes Reinecke <hare@suse.com> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
#
3f0661a4 |
| 25-Jan-2019 |
Bart Van Assche <bvanassche@acm.org> |
scsi: target/core: Remove several state tests from the TMF code
Whether or not a session is being torn down does not affect whether or not SCSI commands are in the task set. Hence remove the "tearin
scsi: target/core: Remove several state tests from the TMF code
Whether or not a session is being torn down does not affect whether or not SCSI commands are in the task set. Hence remove the "tearing down" checks from the TMF code. The TRANSPORT_ISTATE_PROCESSING check is left out because it is now safe to wait for a command that is in that state. The CMD_T_PRE_EXECUTE is left out because abort processing is postponed until after commands have left the pre-execute state since the patch that makes TMF processing synchronous.
See also commit 1c21a48055a6 ("target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK").
Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6 |
|
#
2c9fa49e |
| 27-Nov-2018 |
Bart Van Assche <bvanassche@acm.org> |
scsi: target/core: Make ABORT and LUN RESET handling synchronous
Instead of invoking target driver callback functions from the context that handles an abort or LUN RESET task management function, on
scsi: target/core: Make ABORT and LUN RESET handling synchronous
Instead of invoking target driver callback functions from the context that handles an abort or LUN RESET task management function, only set the abort flag from that context and perform the actual abort handling from the context of the regular command processing flow. This approach has the advantage that the task management code becomes much easier to read and to verify since the number of potential race conditions against the command processing flow is strongly reduced.
This patch has been tested by running the following two shell commands concurrently for about ten minutes for both the iSCSI and the SRP target drivers ($dev is an initiator device node connected with storage provided by the target driver under test):
* fio with data verification enabled on a filesystem mounted on top of $dev.
* while true; do sg_reset -d $dev; echo -n .; sleep .1; done
Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: David Disseldorp <ddiss@suse.de> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
#
aaa00cc9 |
| 27-Nov-2018 |
Bart Van Assche <bvanassche@acm.org> |
scsi: target/core: Fix TAS handling for aborted commands
The TASK ABORTED STATUS (TAS) bit is defined as follows in SAM: "TASK_ABORTED: this status shall be returned if a command is aborted by a com
scsi: target/core: Fix TAS handling for aborted commands
The TASK ABORTED STATUS (TAS) bit is defined as follows in SAM: "TASK_ABORTED: this status shall be returned if a command is aborted by a command or task management function on another I_T nexus and the control mode page TAS bit is set to one". TAS handling is spread over the target core and the iSCSI target driver. If a LUN RESET is received, the target core will send the TASK_ABORTED response for all commands for which such a response has to be sent. If an ABORT TASK is received, only the iSCSI target driver will send the TASK_ABORTED response for the commands for which that response has to be sent. That is a bug since all target drivers have to honor the TAS bit. Fix this by moving the code that handles TAS from the iSCSI target driver into the target core. Additionally, if a command has been aborted, instead of sending the TASK_ABORTED status from the context that processes the SCSI command send it from the context of the ABORT TMF. The core_tmr_abort_task() change in this patch causes the CMD_T_TAS flag to be set if a TASK_ABORTED status has to be sent back to the initiator that submitted the command. If that flag has been set transport_cmd_finish_abort() will send the TASK_ABORTED response.
Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Mike Christie <mchristi@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: David Disseldorp <ddiss@suse.de> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v4.19.5 |
|
#
30c7ca93 |
| 23-Nov-2018 |
David Disseldorp <ddiss@suse.de> |
scsi: target: drop unnecessary get_fabric_name() accessor from fabric_ops
All fabrics return a const string. In all cases *except* iSCSI the get_fabric_name() string matches fabric_ops.name.
Both f
scsi: target: drop unnecessary get_fabric_name() accessor from fabric_ops
All fabrics return a const string. In all cases *except* iSCSI the get_fabric_name() string matches fabric_ops.name.
Both fabric_ops.get_fabric_name() and fabric_ops.name are user-facing, with the former being used for PR/ALUA state and the latter for ConfigFS (config/target/$name), so we unfortunately need to keep both strings around for now. Replace the useless .get_fabric_name() accessor function with a const string fabric_name member variable.
Signed-off-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3 |
|
#
65422d70 |
| 22-Jun-2018 |
Bart Van Assche <bart.vanassche@wdc.com> |
scsi: target: Fold core_tmr_handle_tas_abort() into transport_cmd_finish_abort()
For the two calls to transport_cmd_finish_abort() outside core_tmr_handle_tas_abort() it is guaranteed that CMD_T_TAS
scsi: target: Fold core_tmr_handle_tas_abort() into transport_cmd_finish_abort()
For the two calls to transport_cmd_finish_abort() outside core_tmr_handle_tas_abort() it is guaranteed that CMD_T_TAS is not set. Use this property to fold core_tmr_handle_tas_abort() into transport_cmd_finish_abort(). This patch does not change any functionality.
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> Reviewed-by: Mike Christie <mchristi@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
#
709d5651 |
| 22-Jun-2018 |
Bart Van Assche <bart.vanassche@wdc.com> |
scsi: target: Simplify core_tmr_handle_tas_abort()
The code that can set CMD_T_TAS is executed by the same thread as the thread that executes core_tmr_handle_tas_abort(). That means that no locking
scsi: target: Simplify core_tmr_handle_tas_abort()
The code that can set CMD_T_TAS is executed by the same thread as the thread that executes core_tmr_handle_tas_abort(). That means that no locking is needed to check CMD_T_TAS from inside core_tmr_handle_tas_abort(). This patch does not change any functionality.
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> Reviewed-by: Mike Christie <mchristi@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
#
00d909a1 |
| 22-Jun-2018 |
Bart Van Assche <bart.vanassche@wdc.com> |
scsi: target: Make the session shutdown code also wait for commands that are being aborted
Target drivers must call target_sess_cmd_list_set_waiting() and target_wait_for_sess_cmds() before freeing
scsi: target: Make the session shutdown code also wait for commands that are being aborted
Target drivers must call target_sess_cmd_list_set_waiting() and target_wait_for_sess_cmds() before freeing a session. Since freeing a session is only safe after all commands that are associated with a session have finished, make target_wait_for_sess_cmds() also wait for commands that are being aborted. Instead of setting a flag in each pending command from target_sess_cmd_list_set_waiting() and waiting in target_wait_for_sess_cmds() on a per-command completion, only set a per-session flag in the former function and wait on a per-session completion in the latter function. This change is safe because once a SCSI initiator system has submitted a command a target system is always allowed to execute it to completion. See also commit 0f4a943168f3 ("target: Fix remote-port TMR ABORT + se_cmd fabric stop").
This patch is based on the following two patches:
* Bart Van Assche, target: Simplify session shutdown code, February 19, 2015 (https://github.com/bvanassche/linux/commit/8df5463d7d7619f2f1b70cfe5172eaef0aa52815).
* Christoph Hellwig, target: Rework session shutdown code, December 7, 2015 (http://thread.gmane.org/gmane.linux.scsi.target.devel/10695).
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> Reviewed-by: Mike Christie <mchristi@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
show more ...
|
Revision tags: v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14 |
|
#
1c21a480 |
| 28-Oct-2017 |
Nicholas Bellinger <nab@linux-iscsi.org> |
target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK
This patch fixes bug where early se_cmd exceptions that occur before backend execution can result in use-after-free if/when a subsequ
target: Avoid early CMD_T_PRE_EXECUTE failures during ABORT_TASK
This patch fixes bug where early se_cmd exceptions that occur before backend execution can result in use-after-free if/when a subsequent ABORT_TASK occurs for the same tag.
Since an early se_cmd exception will have had se_cmd added to se_session->sess_cmd_list via target_get_sess_cmd(), it will not have CMD_T_COMPLETE set by the usual target_complete_cmd() backend completion path.
This causes a subsequent ABORT_TASK + __target_check_io_state() to signal ABORT_TASK should proceed. As core_tmr_abort_task() executes, it will bring the outstanding se_cmd->cmd_kref count down to zero releasing se_cmd, after se_cmd has already been queued with error status into fabric driver response path code.
To address this bug, introduce a CMD_T_PRE_EXECUTE bit that is set at target_get_sess_cmd() time, and cleared immediately before backend driver dispatch in target_execute_cmd() once CMD_T_ACTIVE is set.
Then, check CMD_T_PRE_EXECUTE within __target_check_io_state() to determine when an early exception has occured, and avoid aborting this se_cmd since it will have already been queued into fabric driver response path code.
Reported-by: Donald White <dew@datera.io> Cc: Donald White <dew@datera.io> Cc: Mike Christie <mchristi@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
show more ...
|
Revision tags: v4.13.5, v4.13 |
|
#
88fb2fa7 |
| 16-Aug-2017 |
tangwenji <tang.wenji@zte.com.cn> |
target: fix null pointer regression in core_tmr_drain_tmr_list
The target system kernel crash when the initiator executes the sg_persist -A command,because of the second argument to be set to NULL w
target: fix null pointer regression in core_tmr_drain_tmr_list
The target system kernel crash when the initiator executes the sg_persist -A command,because of the second argument to be set to NULL when core_tmr_lun_reset is called in core_scsi3_pro_preempt function.
This fixes a regression originally introduced by:
commit 51ec502a32665fed66c7f03799ede4023b212536 Author: Bart Van Assche <bart.vanassche@sandisk.com> Date: Tue Feb 14 16:25:54 2017 -0800
target: Delete tmr from list before processing
Signed-off-by: tangwenji <tang.wenji@zte.com.cn> Cc: stable@vger.kernel.org # 4.11+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
show more ...
|
Revision tags: v4.12 |
|
#
c00e6220 |
| 23-May-2017 |
Bart Van Assche <bart.vanassche@sandisk.com> |
target: Introduce a function that shows the command state
Introduce target_show_cmd() and use it where appropriate. If transport_wait_for_tasks() takes too long, make it show the state of the comman
target: Introduce a function that shows the command state
Introduce target_show_cmd() and use it where appropriate. If transport_wait_for_tasks() takes too long, make it show the state of the command it is waiting for.
(Add missing brackets around multi-line conditions - nab)
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Andy Grover <agrover@redhat.com> Cc: David Disseldorp <ddiss@suse.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
show more ...
|
#
73d4e580 |
| 02-Jun-2017 |
Nicholas Bellinger <nab@linux-iscsi.org> |
target: Fix kref->refcount underflow in transport_cmd_finish_abort
This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED when a fabric driver drops it's second reference from below the
target: Fix kref->refcount underflow in transport_cmd_finish_abort
This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED when a fabric driver drops it's second reference from below the target_core_tmr.c based callers of transport_cmd_finish_abort().
Recently with the conversion of kref to refcount_t, this bug was manifesting itself as:
[705519.601034] refcount_t: underflow; use-after-free. [705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs [705539.719111] ------------[ cut here ]------------ [705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51
Since the original kref atomic_t based kref_put() didn't check for underflow and only invoked the final callback when zero was reached, this bug did not manifest in practice since all se_cmd memory is using preallocated tags.
To address this, go ahead and propigate the existing return from transport_put_cmd() up via transport_cmd_finish_abort(), and change transport_cmd_finish_abort() + core_tmr_handle_tas_abort() callers to only do their local target_put_sess_cmd() if necessary.
Reported-by: Bart Van Assche <bart.vanassche@sandisk.com> Tested-by: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Mike Christie <mchristi@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Himanshu Madhani <himanshu.madhani@qlogic.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: stable@vger.kernel.org # 3.14+ Tested-by: Gary Guo <ghg@datera.io> Tested-by: Chu Yuan Lin <cyl@datera.io> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
show more ...
|
Revision tags: v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10 |
|
#
c87ba9c4 |
| 19-Jan-2017 |
Nicholas Bellinger <nab@daterainc.com> |
target: Add counters for ABORT_TASK success + failure
This patch introduces two counters for ABORT_TASK success + failure under:
/sys/kernel/config/target/core/$HBA/$DEV/statistics/scsi_tgt_dev/
target: Add counters for ABORT_TASK success + failure
This patch introduces two counters for ABORT_TASK success + failure under:
/sys/kernel/config/target/core/$HBA/$DEV/statistics/scsi_tgt_dev/
that are useful for diagnosing various backend device latency and front fabric issues.
Normally when folks see alot of aborts_complete happening, it means the backend device I/O completion latency is high, and not returning completions fast enough before host side timeouts trigger.
And normally when folks see alot of aborts_no_task, it means completions are being posted by target-core into fabric driver code, but the responses aren't making it back to the host.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
show more ...
|