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

[Damien Le Moal <dlemoal@kernel.org>]

On 1/2/26 19:24, Niklas Cassel wrote:
> 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?

I can try reusing. Let's see how that looks.



-- 
Damien Le Moal
Western Digital Research