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

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

On 12/31/25 20:39, Niklas Cassel wrote:
> On Sat, Dec 20, 2025 at 09:21:40AM +0900, Damien Le Moal wrote:
>> @@ -1702,6 +1779,17 @@ static int ata_scsi_defer(struct ata_port *ap, struct ata_queued_cmd *qc)
>>  	if (!ret)
>>  		return 0;
>>  
>> +	/*
>> +	 * We must defer this qc: if this is not an NCQ command, keep this qc
>> +	 * as a deferred one and wait for all on-going NCQ commands to complete
>> +	 * before issuing it with the deferred qc work.
>> +	 */
>> +	if (!ata_is_ncq(qc->tf.protocol)) {
>> +		ap->deferred_qc = qc;
>> +		return SCSI_MLQUEUE_DEVICE_BUSY;
> 
> Here you save the qc, and you return SCSI_MLQUEUE_DEVICE_BUSY;
> SCSI_MLQUEUE_DEVICE_BUSY will cause the block layer to reinsert the request
> in the queue, so you will get the same request sent to ata_scsi_translate()
> again, even though you have save it. A little ugly IMO.

No it will not cause a requeue in this case because this change:

 	rc = ata_scsi_defer(ap, qc);
-	if (rc)
+	if (rc) {
+		if (qc == ap->deferred_qc)
+			return 0;

ensures that we return "0", thus telling the scsi and block layer that the
command/request was accepted, but we do *not* call ata_qc_issue() for that qc.
It is deferred and will be issued by the deferred qc work once the queue drains.

> It seems like you are relying on the ata_scsi_qc_new() call will give you
> the same *qc as the one you have stored...

No because we will not see that request/command again since we told the scsi
layer that we accepted it (but did not issue it yet, but the scsi layer does not
need to know that).

>>  	rc = ata_scsi_defer(ap, qc);
>> -	if (rc)
>> +	if (rc) {
>> +		if (qc == ap->deferred_qc)
>> +			return 0;
> 
> ...and then you have this code here, to do nothing in that case.

Yes, we do not issue the qc in this case. But the "return 0" tells the scsi
layer that we accepted the command, so as far as scsi is concerned, the command
was "issued".

> But, are we guaranteed that we will always get the same qc?

We will not see the same command again because we told the scsi layer we
accepted it with the above "return 0".

> Have you tried this both with and without mq-deadline?
> And on both ahci and libsas HBAs?

Yes to all.


-- 
Damien Le Moal
Western Digital Research