linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"target-devel@vger.kernel.org" <target-devel@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [RFC PATCH 2/8] scsi: add REQ_OP_VERIFY support
Date: Thu, 11 Nov 2021 08:07:39 +0000	[thread overview]
Message-ID: <cb9cac6d-1206-0bd3-0883-dc7f1a9fcc78@nvidia.com> (raw)
In-Reply-To: <bd36ee58-8273-cd0a-295e-0c66b0142bcd@opensource.wdc.com>

On 11/4/2021 5:33 AM, Damien Le Moal wrote:
> External email: Use caution opening links or attachments
> 
> 
> On 2021/11/04 15:46, Chaitanya Kulkarni wrote:
>> From: Chaitanya Kulkarni <kch@nvidia.com>
>>
>> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
>> ---
>>   drivers/scsi/sd.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++
>>   drivers/scsi/sd.h |  1 +
>>   2 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
>> index a3d2d4bc4a3d..7f2c4eb98cf8 100644
>> --- a/drivers/scsi/sd.c
>> +++ b/drivers/scsi/sd.c
>> @@ -106,6 +106,7 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_ZBC);
>>
>>   static void sd_config_discard(struct scsi_disk *, unsigned int);
>>   static void sd_config_write_same(struct scsi_disk *);
>> +static void sd_config_verify(struct scsi_disk *sdkp);
>>   static int  sd_revalidate_disk(struct gendisk *);
>>   static void sd_unlock_native_capacity(struct gendisk *disk);
>>   static int  sd_probe(struct device *);
>> @@ -995,6 +996,41 @@ static blk_status_t sd_setup_write_zeroes_cmnd(struct scsi_cmnd *cmd)
>>        return sd_setup_write_same10_cmnd(cmd, false);
>>   }
>>
>> +static void sd_config_verify(struct scsi_disk *sdkp)
>> +{
>> +     struct request_queue *q = sdkp->disk->queue;
>> +
>> +     /* XXX: use same pattern as sd_config_write_same(). */
>> +     blk_queue_max_verify_sectors(q, UINT_MAX >> 9);
> 
> VERIFY 10, 12, 16 and 32 commands are optional and may not be implemented by a
> device. So setting this unconditionally is wrong.
> At the very least you must have an "if (sdkp->verify_16)" here, and call
> "blk_queue_max_verify_sectors(q, 0);" if the device does not support verify.
> 

Yes, I put it together for the RFC, this needs to consider the device
unsupported case just like what we do for write zeroes and emulate the
same.

>> +}
>> +
>> +static blk_status_t sd_setup_verify_cmnd(struct scsi_cmnd *cmd)
>> +{
>> +       struct request *rq = cmd->request;
>> +       struct scsi_device *sdp = cmd->device;
>> +       struct scsi_disk *sdkp = scsi_disk(rq->rq_disk);
>> +       u64 lba = sectors_to_logical(sdp, blk_rq_pos(rq));
>> +       u32 nr_blocks = sectors_to_logical(sdp, blk_rq_sectors(rq));
>> +
>> +       if (!sdkp->verify_16)
>> +            return BLK_STS_NOTSUPP;
> 
> I think this should be "return BLK_STS_TARGET;"
> 
>> +
>> +       cmd->cmd_len = 16;
>> +       cmd->cmnd[0] = VERIFY_16;
> 
> And what if the device supports VERIFY 10 or 12 but not VERIFY 16 ?

For first implementation we can only VERIFY 16, later we can add cases 
for VERIFY 10-12 versions.

> 
>> +       /* skip veprotect / dpo / bytchk */
>> +       cmd->cmnd[1] = 0;
>> +       put_unaligned_be64(lba, &cmd->cmnd[2]);
>> +       put_unaligned_be32(nr_blocks, &cmd->cmnd[10]);
>> +       cmd->cmnd[14] = 0;
>> +       cmd->cmnd[15] = 0;
>> +
>> +       cmd->allowed = SD_MAX_RETRIES;
>> +       cmd->sc_data_direction = DMA_NONE;
>> +       cmd->transfersize = 0;
>> +
>> +       return BLK_STS_OK;
>> +}
>> +
>>   static void sd_config_write_same(struct scsi_disk *sdkp)
>>   {
>>        struct request_queue *q = sdkp->disk->queue;
>> @@ -1345,6 +1381,8 @@ static blk_status_t sd_init_command(struct scsi_cmnd *cmd)
>>                }
>>        case REQ_OP_WRITE_ZEROES:
>>                return sd_setup_write_zeroes_cmnd(cmd);
>> +     case REQ_OP_VERIFY:
>> +             return sd_setup_verify_cmnd(cmd);
>>        case REQ_OP_WRITE_SAME:
>>                return sd_setup_write_same_cmnd(cmd);
>>        case REQ_OP_FLUSH:
>> @@ -2029,6 +2067,7 @@ static int sd_done(struct scsi_cmnd *SCpnt)
>>        switch (req_op(req)) {
>>        case REQ_OP_DISCARD:
>>        case REQ_OP_WRITE_ZEROES:
>> +     case REQ_OP_VERIFY:
>>        case REQ_OP_WRITE_SAME:
>>        case REQ_OP_ZONE_RESET:
>>        case REQ_OP_ZONE_RESET_ALL:
>> @@ -3096,6 +3135,17 @@ static void sd_read_write_same(struct scsi_disk *sdkp, unsigned char *buffer)
>>                sdkp->ws10 = 1;
>>   }
>>
>> +static void sd_read_verify(struct scsi_disk *sdkp, unsigned char *buffer)
>> +{
>> +       struct scsi_device *sdev = sdkp->device;
>> +
>> +       sd_printk(KERN_INFO, sdkp, "VERIFY16 check.\n");
> 
> Remove this message please.
> 
>> +       if (scsi_report_opcode(sdev, buffer, SD_BUF_SIZE, VERIFY_16) == 1) {
>> +            sd_printk(KERN_INFO, sdkp, " VERIFY16 in ON .\n");
> 
> And this one too.
> 
>> +               sdkp->verify_16 = 1;
> 
> Why not checking for VERIFY 10 and 12 if VERIFY 16 is not supported ?
> Also, why don't you call "blk_queue_max_verify_sectors(q, UINT_MAX >> 9);" here
> instead of adding the not so useful sd_config_verify() helper ?
> 

Okay, let me see if I can add that in V1.

>> +       }
>> +}
>> +
>>   static void sd_read_security(struct scsi_disk *sdkp, unsigned char *buffer)
>>   {
>>        struct scsi_device *sdev = sdkp->device;
>> @@ -3224,6 +3274,7 @@ static int sd_revalidate_disk(struct gendisk *disk)
>>                sd_read_cache_type(sdkp, buffer);
>>                sd_read_app_tag_own(sdkp, buffer);
>>                sd_read_write_same(sdkp, buffer);
>> +             sd_read_verify(sdkp, buffer);
>>                sd_read_security(sdkp, buffer);
>>        }
>>
>> @@ -3265,6 +3316,7 @@ static int sd_revalidate_disk(struct gendisk *disk)
>>
>>        set_capacity_and_notify(disk, logical_to_sectors(sdp, sdkp->capacity));
>>        sd_config_write_same(sdkp);
>> +     sd_config_verify(sdkp);
>>        kfree(buffer);
>>
>>        /*
>> diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h
>> index b59136c4125b..94a86bf6dac4 100644
>> --- a/drivers/scsi/sd.h
>> +++ b/drivers/scsi/sd.h
>> @@ -120,6 +120,7 @@ struct scsi_disk {
>>        unsigned        lbpvpd : 1;
>>        unsigned        ws10 : 1;
>>        unsigned        ws16 : 1;
>> +     unsigned        verify_16 : 1;
> 
> See right above this line how write same supports the 10 and 16 variants. I
> think you need the same here. And very likely, you also need the 32 version in
> case the device has DIF/DIX (type 2 protection).
> 

Agree with write same 10/16 versions, let me see if I can add that for V1.

>>        unsigned        rc_basis: 2;
>>        unsigned        zoned: 2;
>>        unsigned        urswrz : 1;
>>
> 
> 
> --
> Damien Le Moal
> Western Digital Research
> 

Thanks for the comments Damien.



  reply	other threads:[~2021-11-11  8:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04  6:46 [RFC PATCH 0/8] block: add support for REQ_OP_VERIFY Chaitanya Kulkarni
2021-11-04  6:46 ` [RFC PATCH 1/8] " Chaitanya Kulkarni
2021-11-04 17:25   ` Darrick J. Wong
2021-11-11  8:01     ` Chaitanya Kulkarni
2021-11-04  6:46 ` [RFC PATCH 2/8] scsi: add REQ_OP_VERIFY support Chaitanya Kulkarni
2021-11-04 12:33   ` Damien Le Moal
2021-11-11  8:07     ` Chaitanya Kulkarni [this message]
2021-11-04  6:46 ` [RFC PATCH 3/8] nvme: add support for the Verify command Chaitanya Kulkarni
2021-11-04 22:44   ` Keith Busch
2021-11-11  8:09     ` Chaitanya Kulkarni
2021-11-04  6:46 ` [PATCH 4/8] nvmet: add Verify command support for bdev-ns Chaitanya Kulkarni
2021-11-04  6:46 ` [RFC PATCH 5/8] nvmet: add Verify emulation " Chaitanya Kulkarni
2021-11-04  6:46 ` [RFC PATCH 6/8] nvmet: add verify emulation support for file-ns Chaitanya Kulkarni
2021-11-04  6:46 ` [RFC PATCH 7/8] null_blk: add REQ_OP_VERIFY support Chaitanya Kulkarni
2021-11-04  6:46 ` [RFC PATCH 8/8] md: add support for REQ_OP_VERIFY Chaitanya Kulkarni
2021-11-11  8:13   ` Chaitanya Kulkarni
2021-11-12 15:19     ` Mike Snitzer
2021-11-04  7:14 ` [RFC PATCH 0/8] block: " Christoph Hellwig
2021-11-04  9:27   ` Chaitanya Kulkarni
2021-11-04 17:32     ` Darrick J. Wong
2021-11-04 17:34       ` Christoph Hellwig
2021-11-04 22:37         ` Keith Busch
2021-11-05  8:25           ` javier
2021-11-11  8:18       ` Chaitanya Kulkarni
2021-11-04 15:16 ` Douglas Gilbert
2021-11-11  8:27   ` Chaitanya Kulkarni

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=cb9cac6d-1206-0bd3-0883-dc7f1a9fcc78@nvidia.com \
    --to=chaitanyak@nvidia.com \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=target-devel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).