Re: [PATCH v2 0/2] scsi: target: iscsi: fix stalled aborted WRITE commands

[Laurence Oberman]

On Sun, 2026-10-25 at 09:40 -0700, Bart Van Assche wrote:
> On 10/25/26 7:43 AM, Laurence Oberman wrote:
> > Gentle ping:
> Please take a look at the attached review report. The report has been
> generated by an LLM. As known LLMs may make mistakes.
> 
> Bart.

Hello Bart,
Thank you very much for using your LLM review this. I am following up
with a v3.

The report was right about the one thing: the claim in v2 did not cover
every site that completes an aborted WRITE_PENDING command, and my
answer to the Sashiko review wrongly assumed 
iscsit_check_dataout_hdr() checked it. The upcoming v3 adds patch 3 for
that site and patch 4 for the DATAOUT_SEND_TO_TRANSPORT path, and the
cover letter corrects the Sashiko answer. The comment reword and the
patch 2 commit-message cleanup are in there too.

Two things in the report are not correct, in case the same tool is used
again:

d5869dae5080 is not confined to 7.3/scsi-staging:

  $ git tag --contains d5869dae5080
  mkp-scsi-fixes
  mkp-scsi-staging
  v7.3
  v7.3-rc2
  ... v7.3-rc7

It went in via mkp-scsi-fixes during the 7.3 cycle, it is in released
v7.3, it carries CVE-2026-97951, and it is in 5.10.y, 5.15.y, 6.1.y,
6.6.y, 6.12.y, 6.18.y and 7.2.y. That does not change the conclusion
that the gap belongs in this series, but it is why patch 3 has Cc:
stable, and why it may be better taken standalone for those branches,
none of which carry patch 1's helper.

It seems aaa00cc93c1d is yours from git history.

  $ git show --no-patch --format='%an <%ae> %ad' aaa00cc93c1d
  Bart Van Assche <bvanassche@xxxxxxx> Tue Nov 27 15:52:02 2018 -0800

It is the right Fixes: for patch 1, though, and patch 1 now carries it.
git log -L on that hunk shows your commit replaced a
transport_check_aborted_status() call -- which sent the delayed
TASK_ABORTED status -- with a bare CMD_T_ABORTED test and a return.
That works where the core can finish the command itself, but a WRITE
still in TRANSPORT_WRITE_PENDING has never reached the backend, so the
core's abort path is itself waiting in target_put_cmd_and_wait() for
the fabric. The other three commits touching that hunk since 2011 are
cosmetic.

Thank you
Laurence