* [PATCH v2] scsi: target: put lun_ref at end of tmr processing
@ 2020-05-13 15:34 ` Bodo Stroesser
0 siblings, 0 replies; 4+ messages in thread
From: Bodo Stroesser @ 2020-05-13 15:34 UTC (permalink / raw)
To: martin.petersen, bvanassche, mchristi, linux-scsi, target-devel, bly
Cc: Bodo Stroesser, stable
Testing with Loopback I found, that after a Loopback LUN
has executed a TMR, I can no longer unlink the LUN.
The rm command hangs in transport_clear_lun_ref() at
wait_for_completion(&lun->lun_shutdown_comp)
The reason is, that transport_lun_remove_cmd() is not
called at the end of target_tmr_work().
It seems, that in other fabrics this call happens implicitly
when the fabric drivers call transport_generic_free_cmd()
during their ->queue_tm_rsp().
Unfortunately Loopback seems to not comply to the common way
of calling transport_generic_free_cmd() from ->queue_*().
Instead it calls transport_generic_free_cmd() from its
->check_stop_free() only.
But the ->check_stop_free() is called by
transport_cmd_check_stop_to_fabric() after it has reset the
se_cmd->se_lun pointer.
Therefore the following transport_generic_free_cmd() skips the
transport_lun_remove_cmd().
So this patch re-adds the transport_lun_remove_cmd() at the end
of target_tmr_work(), which was removed during commit
2c9fa49e100f962af988f1c0529231bf14905cda
"scsi: target/core: Make ABORT and LUN RESET handling synchronous"
For fabrics using transport_generic_free_cmd() in the usual way
the double call to transport_lun_remove_cmd() doesn't harm, as
transport_lun_remove_cmd() checks for this situation and does
not release lun_ref twice.
Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous")
Cc: stable@vger.kernel.org
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Tested-by: Bryant G. Ly <bryangly@gmail.com>
Reviewed-by: Bart van Assche <bvanassche@acm.org>
---
v2:
- Resend of the same patch with added tags "Fixes:",
"Cc: stable@.." and "Reviewed-by:"
drivers/target/target_core_transport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 594b724bbf79..264a822c0bfa 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3350,6 +3350,7 @@ static void target_tmr_work(struct work_struct *work)
cmd->se_tfo->queue_tm_rsp(cmd);
+ transport_lun_remove_cmd(cmd);
transport_cmd_check_stop_to_fabric(cmd);
return;
--
2.12.3
^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH v2] scsi: target: put lun_ref at end of tmr processing
@ 2020-05-13 15:34 ` Bodo Stroesser
0 siblings, 0 replies; 4+ messages in thread
From: Bodo Stroesser @ 2020-05-13 15:34 UTC (permalink / raw)
To: martin.petersen, bvanassche, mchristi, linux-scsi, target-devel, bly
Cc: Bodo Stroesser, stable
Testing with Loopback I found, that after a Loopback LUN
has executed a TMR, I can no longer unlink the LUN.
The rm command hangs in transport_clear_lun_ref() at
wait_for_completion(&lun->lun_shutdown_comp)
The reason is, that transport_lun_remove_cmd() is not
called at the end of target_tmr_work().
It seems, that in other fabrics this call happens implicitly
when the fabric drivers call transport_generic_free_cmd()
during their ->queue_tm_rsp().
Unfortunately Loopback seems to not comply to the common way
of calling transport_generic_free_cmd() from ->queue_*().
Instead it calls transport_generic_free_cmd() from its
->check_stop_free() only.
But the ->check_stop_free() is called by
transport_cmd_check_stop_to_fabric() after it has reset the
se_cmd->se_lun pointer.
Therefore the following transport_generic_free_cmd() skips the
transport_lun_remove_cmd().
So this patch re-adds the transport_lun_remove_cmd() at the end
of target_tmr_work(), which was removed during commit
2c9fa49e100f962af988f1c0529231bf14905cda
"scsi: target/core: Make ABORT and LUN RESET handling synchronous"
For fabrics using transport_generic_free_cmd() in the usual way
the double call to transport_lun_remove_cmd() doesn't harm, as
transport_lun_remove_cmd() checks for this situation and does
not release lun_ref twice.
Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous")
Cc: stable@vger.kernel.org
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Tested-by: Bryant G. Ly <bryangly@gmail.com>
Reviewed-by: Bart van Assche <bvanassche@acm.org>
---
v2:
- Resend of the same patch with added tags "Fixes:",
"Cc: stable@.." and "Reviewed-by:"
drivers/target/target_core_transport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 594b724bbf79..264a822c0bfa 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3350,6 +3350,7 @@ static void target_tmr_work(struct work_struct *work)
cmd->se_tfo->queue_tm_rsp(cmd);
+ transport_lun_remove_cmd(cmd);
transport_cmd_check_stop_to_fabric(cmd);
return;
--
2.12.3
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] scsi: target: put lun_ref at end of tmr processing
2020-05-13 15:34 ` Bodo Stroesser
@ 2020-05-15 1:10 ` Martin K. Petersen
-1 siblings, 0 replies; 4+ messages in thread
From: Martin K. Petersen @ 2020-05-15 1:10 UTC (permalink / raw)
To: mchristi, linux-scsi, target-devel, bly, Bodo Stroesser, bvanassche
Cc: Martin K . Petersen, stable
On Wed, 13 May 2020 17:34:43 +0200, Bodo Stroesser wrote:
> Testing with Loopback I found, that after a Loopback LUN
> has executed a TMR, I can no longer unlink the LUN.
> The rm command hangs in transport_clear_lun_ref() at
> wait_for_completion(&lun->lun_shutdown_comp)
> The reason is, that transport_lun_remove_cmd() is not
> called at the end of target_tmr_work().
>
> [...]
Applied to 5.7/scsi-fixes, thanks!
[1/1] scsi: target: Put lun_ref at end of tmr processing
https://git.kernel.org/mkp/scsi/c/f2e6b75f6ee8
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] scsi: target: put lun_ref at end of tmr processing
@ 2020-05-15 1:10 ` Martin K. Petersen
0 siblings, 0 replies; 4+ messages in thread
From: Martin K. Petersen @ 2020-05-15 1:10 UTC (permalink / raw)
To: mchristi, linux-scsi, target-devel, bly, Bodo Stroesser, bvanassche
Cc: Martin K . Petersen, stable
On Wed, 13 May 2020 17:34:43 +0200, Bodo Stroesser wrote:
> Testing with Loopback I found, that after a Loopback LUN
> has executed a TMR, I can no longer unlink the LUN.
> The rm command hangs in transport_clear_lun_ref() at
> wait_for_completion(&lun->lun_shutdown_comp)
> The reason is, that transport_lun_remove_cmd() is not
> called at the end of target_tmr_work().
>
> [...]
Applied to 5.7/scsi-fixes, thanks!
[1/1] scsi: target: Put lun_ref at end of tmr processing
https://git.kernel.org/mkp/scsi/c/f2e6b75f6ee8
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-15 1:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-13 15:34 [PATCH v2] scsi: target: put lun_ref at end of tmr processing Bodo Stroesser
2020-05-13 15:34 ` Bodo Stroesser
2020-05-15 1:10 ` Martin K. Petersen
2020-05-15 1:10 ` Martin K. Petersen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.