Re: [PATCH v3 2/2] ata: libata-scsi: avoid passthrough command starvation

[Niklas Cassel <cassel@kernel.org>]

On Fri, Jan 02, 2026 at 09:47:57AM +0900, Damien Le Moal wrote:
> On 12/31/25 20:17, Niklas Cassel wrote:
> 
> You are kind of proving my point here: I feel that is all much more complicated
> than using the libata internal deferred qc work. Also, involving the SCSI layer
> about non-NCQ commands deferral is kind of a layering violation as the
> non-queueable command concept does not exist in SCSI.

Personally, I think my suggestion is much less complicated, as we do not need
to think about when to clear ap->deferred_qc or when to stop the workqueue,
during the special cases like when a reset occurs, or when a NCQ command fails.
I'm a little bit worried that there are some other special cases that we might
be overlooking.

Reusing the method we already use for CDL commands would completely sidestep
these issues, as we are putting the command in the SCSI EH workqueue, which
will requeue the command for us.

I do not see it as a layering violation, as we simply wait for the queue to
drain, then let SCSI EH retry/insert the failed/deferred non-NCQ command in
the normal SCSI queue.

The non-NCQ should be the only command that is failed, but even if there was
a NCQ command that failed as well, we will retry scmd->allowed times anyway,
so the non-NCQ command should eventually be the only command that is retried.


> libata must act as a SATL and the SAT specifications are clear about what a SATL
> implementation can do for non-NCQ commands. Referring to SATA6r01:
> 
> 6.2.5 Commands the SATL queues internally
> If the translation of a SCSI command requires the SATL to send an ATA non-NCQ
> command to the ATA device while one or more ATA commands are active, then the
> SATL shall:
> a) suspend processing of that SCSI command, and:
> 	1) maintain the SCSI command in a task set;
> 	2) resume processing of that SCSI command when the ATA device returns command
> complete for all ATA commands the SATL has previously sent to the ATA device; and
> 	3) after that SCSI command completes, resume processing of other SCSI commands;
> b) return TASK SET FULL status for that SCSI command; or
> c) return BUSY status for that SCSI command.
> 
> What you are proposing does not nicely fit. This patch essentially implements
> option (a). Option (c) is the current code, which causes the issue for
> multi-queue cases (note that AHCI is not affected because it is single queue).
> And option (c) would be mostly equivalent to (b) and cause the same issue as
> that would involve a requeue too.

I think my suggestion would be a)
since by triggering EH, we wait for all commands to complete,
then resume processing of the non-NCQ command.

That said, I know that you had plans to change the processing of CDL commands
to use a workqueue instead of EH, so in the grand scheme of things, if we will
migrate to use a workqueue instead of EH for CDL, perhaps it makes sense if we
also use a workqueue for a deferred non-NCQ command.

Will we be able to use the same workqueue, or will we soon have two different
workqueues?


Kind regards,
Niklas