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

[Damien Le Moal]

On 10/30/26 12:19, Zhao Gongyi wrote:
> 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.

Looking at the list of scsi sense code, I think the data phase may be most
appropriate, but with a qualifier. So why not use: DATA_IN_BUFFER_ERROR (0x4B0A).

The other one that I like would be SCSI_TO_HOST_SYSTEM_INTERFACE_FAILURE
(0x5400), but the DATA IN BUFFER ERROR may be clearer.

-- 
Damien Le Moal
Western Digital Research