From: Bart Van Assche <bvanassche@acm.org>
To: Laurence Oberman <loberman@redhat.com>, mkp@kernel.org
Cc: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
mlombard@redhat.com, michael.christie@oracle.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/3] scsi: target: iscsi: fix stalled and doubly completed aborted WRITEs
Date: Mon, 26 Oct 2026 08:24:40 -0700 [thread overview]
Message-ID: <79480408-8403-4a93-a2dc-c5f01864a20c@acm.org> (raw)
In-Reply-To: <20261026150710.1063511-1-loberman@redhat.com>
On 10/26/26 8:07 AM, Laurence Oberman wrote:
> On moving the one-shot guard into target core:
>
> This will be explored later on but is not in scope for this series; it
> changes the path every fabric completes through and I have no way to test
> easily in iSER, FC or SRP right now.
I don't think that argument holds. Fabric drivers that complete an
aborted command exactly once never trigger a one-shot guard in
target_cmd_interrupted(), so their behavior wouldn't change. The guard
can be a new transport_state bit that is tested and set under
t_state_lock, and the CMD_T_ABORTED test can be moved under that lock
too. Today target_cmd_interrupted() reads transport_state without
holding any lock. That would:
- make the iSCSI-private completion_claimed member and both new helpers
unnecessary;
- close the race that patch 3 only narrows (CMD_T_ABORTED being set
between the iSCSI test and target_cmd_interrupted());
- also cover the sites this series doesn't touch, e.g. the deferred
ICF_OOO_CMDSN path where iscsit_execute_ooo_cmdsns() ends up calling
target_execute_cmd() for an aborted command without taking the claim.
Please consider doing this instead of adding iSCSI-specific
bookkeeping. If the iSCSI-only approach is kept for stable, please
explain in the cover letter why the core approach isn't suitable.
Patch 1/3:
> Fixes: aaa00cc93c1d ("scsi: target/core: Fix TAS handling for aborted
commands")
transport_check_aborted_status() only sent the TASK ABORTED status. It
didn't drop the reference that the abort path now waits on. Nothing
waited in target_put_cmd_and_wait() until commit 2c9fa49e100f
("scsi: target/core: Make ABORT and LUN RESET handling synchronous").
I think that's the commit this patch fixes, or at least it should be
mentioned too. Both commits went into v5.0, so stable coverage doesn't
change.
> +bool iscsit_claim_completion_locked(struct iscsit_cmd *cmd)
> +{
> + lockdep_assert_held(&cmd->se_cmd.t_state_lock);
Please also add __must_hold(&cmd->se_cmd.t_state_lock) to the
declaration so that Clang's context analysis can check this at compile
time.
> +/* Complete an aborted command at most once. Must not hold
t_state_lock. */
> +void iscsit_complete_aborted_cmd(struct iscsit_cmd *cmd)
Please change that comment into a __must_not_hold() annotation.
> + spin_lock_irqsave(&se_cmd->t_state_lock, flags);
All callers run in process context with interrupts enabled, and
iscsit_release_commands_from_conn() uses spin_lock_irq() on the same
lock. spin_lock_irq() is enough here.
> + bool completion_claimed;
Please add __guarded_by(&se_cmd.t_state_lock) instead of just stating
in a comment which lock protects this member.
Patch 2/3: looks fine to me, assuming the series stays as it is.
Patch 3/3: as explained above, this patch narrows the race but doesn't
close it, and the ooo_cmdsn branch right above the new code still
defers to a path that doesn't take the claim. I'd rather see this
solved in target_cmd_interrupted() than merge a partial fix that will
be replaced later anyway.
Thanks,
Bart.
next prev parent reply other threads:[~2026-10-26 15:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 15:07 Laurence Oberman
2026-10-26 15:07 ` [PATCH v4 1/3] scsi: target: iscsi: Complete an aborted WRITE stuck before the first R2T Laurence Oberman
2026-10-26 15:07 ` [PATCH v4 2/3] scsi: target: iscsi: Claim the completion in __iscsit_check_dataout_hdr() Laurence Oberman
2026-10-26 15:07 ` [PATCH v4 3/3] scsi: target: iscsi: Claim the completion on the DataOut submit path Laurence Oberman
2026-10-26 15:24 ` Bart Van Assche [this message]
2026-10-26 16:12 ` [PATCH v4 0/3] scsi: target: iscsi: fix stalled and doubly completed aborted WRITEs Laurence Oberman
2026-10-26 16:47 ` Bart Van Assche
2026-10-26 18:57 ` Laurence Oberman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=79480408-8403-4a93-a2dc-c5f01864a20c@acm.org \
--to=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=loberman@redhat.com \
--cc=michael.christie@oracle.com \
--cc=mkp@kernel.org \
--cc=mlombard@redhat.com \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®