Re: [PATCH v2] ata: libata-scsi: reject data-in commands with a data-out buffer

["Zhao Gongyi" <zhaogongyi@bytedance.com>]

On 10/30/26 9:18 AM, Damien Le Moal wrote:
> Yep, these are the only ones we can catch easily. Other commands we do not look
> at/know about will keep potentially triggering iommu page faults, but that is
> fine as that is not a crash. However, ideally, that should lead to the command
> being failed, which it seems we are unable to do... Did you check if we can
> propagate the fault into a the request to indicate a failure?
> 

Hi Damien,

I checked the DMA mapping and IOMMU fault paths.

For DMA commands, ata_sg_setup() calls dma_map_sg() using qc->dma_dir,
which is derived from the direction supplied with the SG_IO request.
Therefore, for a request declared as DMA_TO_DEVICE, the mapping itself
succeeds with device-read permissions.

If the device subsequently attempts to write through that mapping, the
permission violation is reported asynchronously by the IOMMU. I could
not find a generic mechanism that associates such a fault with the
corresponding ata_queued_cmd or scsi_cmnd and turns it into a
per-command failure.

Some host controllers may also report a host-bus or interface error for
the command, but that appears to be controller-specific and cannot be
relied upon by libata.

Therefore, for the mismatches that libata can identify, rejecting the
command before issuing it still seems necessary. For arbitrary ATAPI or
vendor-specific CDBs whose actual direction libata does not know, I do
not think the generic IOMMU fault can be reliably propagated to the
request.

I will wait for your guidance on the appropriate sense code before
posting v3.

Thanks,
Gongyi