mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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®