Re: [PATCH 0/3] ata: fix deferred QC handling for port multipliers

[Niklas Cassel <cassel@kernel.org>]

On Fri, May 01, 2026 at 03:19:03PM +0100, John Garry wrote:
> On 01/05/2026 13:54, Niklas Cassel wrote:
> 
> As I understand, this deferred QC scheme was intended to solve starvation
> problems for multiqueue SAS HBAs (using libsas-based drivers). libsas has no
> port multiplier support, so I wonder why we make deferred QC scheme work for
> port multiplier, i.e. non-libsas scenario.

Are you certain that there are no libsas HBAs that support port
multipliers?


Basically, before commit:
0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation")

We always aborted a new command, if that would have caused NCQ and non-NCQ
commands to be mixed on the same device.
Regardless if libsas driver or any other SATA driver, e.g. AHCI.


After commit:
0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation")
If sending a non-NCQ command while NCQ commands are in flight,
we instead save the non-NCQ command and issue it as soon all NCQ
commands are finished, from a workqueue.

This commit changed the behavior both for libsas based drivers and
all other SATA drivers, including AHCI, which does support Port
Multipliers.

As you might now, Port Multipliers are not that common, and I think
simply no one tested the change on Port Multipliers before the change
was included.


As you can see in patch 2/3, we basically stop using this deferred QC
issuing via workqueue for Port Multipliers with CBS - when sending
commands to different devices.

For Port Multipliers with FBS support, or PMPs with CBS support where
issuing commands within the same drive, we are still using it.

For PMPs with FBS, I don't see any problem of keep using the workqueue
to issue a deferred QC. It should basically be the same as if directly
connected on the port. (There is no extra logic to handle ap->excl_link.)


For PMPs with CBS, we could keep the same behavior as before, and just
abort the command, if NCQ and non-NCQ are mixed.

The advantage is that the workqueue issuing would not be able to somehow
collide with the ap->excl_link handling for CBS PMPs. Looking at the code,
it "should work", because we always will always have ATA_QCFLAG_CLEAR_EXCL
set on the QC issued by the workqueue.

This would require that we know that PMPs (with CBS) can't be used on
libsas based HBAs. Hell, we could probably do that if we wanted to, since
I don't think that people using an expense SAS HBA with a cheap CBS PMP
(does not not even support FBS) is very common in practice.,,


Kind regards,
Niklas