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

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 wa=
its
>> for the frontend to finish processing.
>>=20
>> If the initiator subsequently sends the remaining dataout PDUs,
>> __iscsit_check_dataout_hdr() catches the payload, stops the dataout time=
r
>> if the sequence is final and finally dumps the data.
>> However, the iSCSI target doesn't trigger the completion process for the=
se
>> aborted commands. Because of this, the abort path hangs indefinitely in
>> target_put_cmd_and_wait(), leading to a deadlocked target worker thread.
>>=20
>> Fix this by explicitly calling target_complete_cmd() when the final data=
out
>> PDU is received for an aborted WRITE command. target_complete_cmd() dete=
cts
>> 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 ("scs=
i:
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