On 11/7/22 21:16, Christoph Hellwig wrote: > On Mon, Nov 07, 2022 at 09:12:57PM +0900, Damien Le Moal wrote: >> On 11/7/22 14:50, Christoph Hellwig wrote: >>> On Mon, Nov 07, 2022 at 09:50:19AM +0900, Damien Le Moal wrote: >>>> Finally, since the block layer should never issue a FUA read >>>> request, warn in ata_build_rw_tf() if we see such request. >>> >>> Couldn't this be triggered using SG_IO passthrough with a SCSI >>> WRITE* command that has the FUA bit set? >> >> Yes indeed. Should I drop the warn ? > > I think the warn needs to go. But don't we also need to handle the > non-NCQ fua case if we don't want to break pure passthrough appliations? > Or do we simply not care? In the latter case we'll at least need a > comment documenting that tradeoff. Actually, this was already handled: for an FUA read without ncq enabed, ata_set_rwcmd_protocol() will return false, leading to ata_build_rw_tf() to return EINVAL, which is then translated to ILLEGAL REQUEST/INVALID FIELD IN CDB in libata-scsi. So passthrough applications attempting FUA reads without NCQ will see an error, as they already did before (modulo the bug with lba28, that is, the error was only for reads to higher LBAs or larger commands). So no additional checks needed I think. -- Damien Le Moal Western Digital Research
