From: Damien Le Moal <dlemoal@kernel.org>
To: Zhao Gongyi <zhaogongyi@bytedance.com>,
Niklas Cassel <cassel@kernel.org>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ata: libata-scsi: reject data-in commands with a data-out buffer
Date: Wed, 4 Nov 2026 05:25:03 +0900 [thread overview]
Message-ID: <f72d88e0-553d-4cc9-af38-9cca183cb814@kernel.org> (raw)
In-Reply-To: <0a4822fe-f283-4cac-8ca3-91f4e8f017e2@bytedance.com>
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
prev parent reply other threads:[~2026-11-03 20:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 9:08 [PATCH] ata: libata-scsi: reject to-device transfers for simulated commands Zhao Gongyi
2026-10-27 21:22 ` Niklas Cassel
2026-10-28 11:39 ` [PATCH v2] ata: libata-scsi: reject data-in commands with a data-out buffer Zhao Gongyi
2026-10-28 13:59 ` Damien Le Moal
2026-10-29 4:37 ` Zhao Gongyi
2026-10-30 1:18 ` Damien Le Moal
2026-10-30 3:19 ` Zhao Gongyi
2026-11-03 20:25 ` Damien Le Moal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f72d88e0-553d-4cc9-af38-9cca183cb814@kernel.org \
--to=dlemoal@kernel.org \
--cc=cassel@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zhaogongyi@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®