On Fri, Dec 30, 2022 at 08:21:59PM +0900, Damien Le Moal wrote:
> On 12/30/22 19:54, Niklas Cassel wrote:
> >
> > Perhaps this commit should more clearly say that this commit only affects
> > the simulated output for a SCSI mode sense command?
> >
> > Currently, the commit message is a bit misleading, since it makes the
> > reader think that a SCSI write command with the FUA bit was not propagated
> > to the device before this commit, which AFAICT, is not true.
>
> It was not with the default libata.fua = 0, since the drive would never be
> exposed as having FUA support. See ata_dev_supports_fua() and its test for
> "!libata_fua" and how that function was used in ata_scsiop_mode_sense().
I see, drivers/scsi/sd.c does a SCSI mode sense to check if FUA is reported
as being supported, and then calls the block layer setter for this.
So changing the simulated SCSI cmd output is sufficient to tell the block
layer that it can send FUA requests to us.
>
> The confusing thing here is that indeed there is no code preventing
> propagating FUA bit to the device in libata-core/libata-scsi for any
> REQ_FUA request. But the fact that devices would never report FUA support
> means that the block layer would never issue a request with REQ_FUA set.
Well, ata_scsi_rw_xlat() is used both for passthrough commands and commands
issued by the block layer.
Just like how ata_scsiop_mode_sense() will be called regardless if it was a
passthrough command or a command issued by the block layer.
ata_scsiop_mode_sense() will not behave differently if it was a command
issued by the block layer or if it was e.g. a SG command.
I would argue that it makes sense (pun intended) for ata_scsi_rw_xlat() to
also behave the same, regardless if it was a command issued by the block
layer of if it was e.g. a SG command, but I will leave that to you to decide.
> That would be possible for passthrough commands only. What is going to
> happen is that we'll now get an error for that write if the drive does not
> support NCQ or has NCQ disabled.
Why would it give an error on a drive that has NCQ disabled?
Your new code looks like this:
static void ata_dev_config_fua(struct ata_device *dev)
{
/* Ignore FUA support if its use is disabled globally */
if (!libata_fua)
goto nofua;
/* Ignore devices without support for WRITE DMA FUA EXT */
if (!(dev->flags & ATA_DFLAG_LBA48) || !ata_id_has_fua(dev->id))
goto nofua;
/* Ignore known bad devices and devices that lack NCQ support */
if (!ata_ncq_supported(dev) || (dev->horkage & ATA_HORKAGE_NO_FUA))
goto nofua;
dev->flags |= ATA_DFLAG_FUA;
return;
nofua:
dev->flags &= ~ATA_DFLAG_FUA;
}
So it should only give an error for a drive where NCQ is not supported.
If NCQ is supported, but disabled, you will still send a ATA_CMD_WRITE_FUA_EXT
command.
Kind regards,
Niklas
