All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Damien Le Moal" <dlemoal@kernel.org>
Cc: cassel@kernel.org, dlemoal@kernel.org,
	linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH v6 2/2] scsi: libsas: terminate deferred commands on time out
Date: Mon, 20 Jul 2026 07:36:56 +0000	[thread overview]
Message-ID: <20260720073656.991C91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720071450.1877625-3-dlemoal@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] A race condition between the SCSI timeout handler and ata_scsi_requeue_deferred_qc(ap, NULL) causes timed-out deferred commands to be silently completed as SUCCESS, leading to data corruption.
--

--- Patch [2]: [PATCH v6 2/2] scsi: libsas: terminate deferred commands on time out ---
commit e25a34ed23fb53d891efaea25a8a4f4ff07ee231
Author: Damien Le Moal <dlemoal@kernel.org>

scsi: libsas: terminate deferred commands on time out

This patch implements the eh_timed_out SCSI host template operation for libsas.
It avoids unnecessary SCSI EH trigger wait times for deferred non-NCQ commands
by utilizing ata_scsi_retry_deferred_qc() for SATA devices, mirroring the
method used in libata-scsi.

> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index b02b4ca5c09e2..dfd7fc2c8cb66 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -1762,8 +1762,7 @@ static void ata_scsi_schedule_deferred_qc(struct ata_link *link)
>  		queue_work(system_highpri_wq, &link->deferred_qc_work);
>  }
>  
> -static void ata_scsi_retry_deferred_qc(struct ata_port *ap,
> -				       struct scsi_cmnd *scmd)
> +void ata_scsi_retry_deferred_qc(struct ata_port *ap, struct scsi_cmnd *scmd)
>  {
>  	unsigned long flags;
>  
> @@ -1771,6 +1770,7 @@ static void ata_scsi_retry_deferred_qc(struct ata_port *ap,
>  	ata_scsi_requeue_deferred_qc(ap, scmd);
>  	spin_unlock_irqrestore(ap->lock, flags);
>  }
> +EXPORT_SYMBOL_GPL(ata_scsi_retry_deferred_qc);

[Severity: Critical]
This is a pre-existing issue, but does exporting and reusing
ata_scsi_retry_deferred_qc() expose us further to a race condition with
ata_scsi_requeue_deferred_qc()?

If a deferred SATA command times out, the block layer marks its request as
MQ_RQ_COMPLETE and enters scsi_timeout(). Concurrently, if EH is scheduled for
another command on the same port, ata_eh_set_pending() can call
ata_scsi_requeue_deferred_qc(ap, NULL).

When called with timedout_scmd == NULL, this clears link->deferred_qc and calls
ata_scsi_qc_done():

drivers/ata/libata-scsi.c:ata_scsi_requeue_deferred_qc() {
    ...
    if (!timedout_scmd) {
        ...
        ata_scsi_qc_done(qc, true, DID_REQUEUE << 16);
        continue;
    }
    ...
}

ata_scsi_qc_done() zeroes qc->flags via ata_qc_free(), and calls scsi_done(),
which the block layer ignores due to the concurrent timeout. The timeout path
then adds the command to EH.

When ata_scsi_cmd_error_handler() runs, it fails to find the QC because
qc->flags is 0, assuming normal successful completion:

drivers/ata/libata-eh.c:ata_scsi_cmd_error_handler() {
    ...
        } else {
            /* Normal completion occurred after
             * SCSI timeout but before this point.
             * Successfully complete it.
             */
            scmd->retries = scmd->allowed;
            scsi_eh_finish_cmd(scmd, &ap->eh_done_q);
        }
    ...
}

Can this race cause timed-out deferred commands to be silently completed as
SUCCESS, leading to silent data corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720071450.1877625-1-dlemoal@kernel.org?part=2

      reply	other threads:[~2026-07-20  7:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  7:14 [PATCH v6 0/2] fixup handling of timeouts with deferred QCs Damien Le Moal
2026-07-20  7:14 ` [PATCH v6 1/2] ata: libata-scsi: terminate deferred commands on time out Damien Le Moal
2026-07-20  7:31   ` sashiko-bot
2026-07-20  9:33     ` Damien Le Moal
2026-07-20  7:14 ` [PATCH v6 2/2] scsi: libsas: " Damien Le Moal
2026-07-20  7:36   ` sashiko-bot [this message]

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=20260720073656.991C91F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.