Re: [PATCH 1/1] target: iscsi: Fix hang for aborted WRITE_PENDING commands

["Maurizio Lombardi" <mlombard@arkamax.eu>]

On Fri Jul 17, 2026 at 6:38 PM CEST, Bart Van Assche wrote:
> On 7/17/26 7:38 AM, 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.
>
> Shouldn't a Fixes: tag be added to this patch?

It's a bit difficult to pinpoint an exact commit.

Probably the roots of this bug could be found in aaa00cc93c1d0fd2693a ("scsi:
target/core: Fix TAS handling for aborted commands"), you are the author
of that commit btw.

But at the time (we are talking about 4.x kernels) the abort mechanism
was working in a different way, target_abort_work didn't even exists and
target_complete_cmd() was quite different...

Maurizio