On Fri, Jul 17, 2026 at 04:38:28PM +0200, Maurizio Lombardi wrote:
> 
> When a LUN_RESET aborts a WRITE command that is in the
> TRANSPORT_WRITE_PENDING state, the target core sets CMD_T_ABORTED and waits
> for the frontend to finish processing.
> 
> If the initiator subsequently sends the remaining dataout PDUs,
> __iscsit_check_dataout_hdr() catches the payload, stops the dataout timer
> if the sequence is final and finally dumps the data.
> However, the iSCSI target doesn't trigger the completion process for these
> aborted commands. Because of this, the abort path hangs indefinitely in
> target_put_cmd_and_wait(), leading to a deadlocked target worker thread.
> 
> Fix this by explicitly calling target_complete_cmd() when the final dataout
> PDU is received for an aborted WRITE command. target_complete_cmd() detects
> the CMD_T_ABORTED flag and cleanly routes the command into target_abort_work,
> allowing the abort completion to successfully unblock.
> 
> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
> ---
>  drivers/target/iscsi/iscsi_target.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
> index 62ada3a52210..124ff269b8e7 100644
> --- a/drivers/target/iscsi/iscsi_target.c
> +++ b/drivers/target/iscsi/iscsi_target.c
> @@ -1533,8 +1533,10 @@ __iscsit_check_dataout_hdr(struct iscsit_conn *conn, void *buf,
>                  */
>                 if (se_cmd->transport_state & CMD_T_ABORTED) {
>                         if (hdr->flags & ISCSI_FLAG_CMD_FINAL &&
> -                           --cmd->outstanding_r2ts < 1)
> +                           --cmd->outstanding_r2ts < 1) {
>                                 iscsit_stop_dataout_timer(cmd);
> +                               target_complete_cmd(se_cmd, SAM_STAT_TASK_ABORTED);
> +                       }
> 
>                         return iscsit_dump_data_payload(conn, payload_length, 1);
>                 }
> --
> 2.55.0
> 

Hi Maurizio,

We also faced that bug several years ago. We solved it by removing all
leftovers of hanling of aborted commands in iscsi, because the handling
of aborted commands moved to target core an age ago. iSCSI will collect
data as usual and pass the command to target core, it in its turns will
abort the command.


BR,
 Dmitry