linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: "Darrick J. Wong" <djwong@kernel.org>
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>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"target-devel@vger.kernel.org" <target-devel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [RFC PATCH 1/8] block: add support for REQ_OP_VERIFY
Date: Thu, 11 Nov 2021 08:01:07 +0000	[thread overview]
Message-ID: <3875c1ba-e70e-baf4-bc3e-d0a7e22a7fc4@nvidia.com> (raw)
In-Reply-To: <20211104172558.GH2237511@magnolia>

On 11/4/2021 10:25 AM, Darrick J. Wong wrote:
> External email: Use caution opening links or attachments
> 
> 
> On Wed, Nov 03, 2021 at 11:46:27PM -0700, Chaitanya Kulkarni wrote:
>> From: Chaitanya Kulkarni <kch@nvidia.com>
>>
>> This adds a new block layer operation to offload verifying a range of
>> LBAs. This support is needed in order to provide file systems and
>> fabrics, kernel components to offload LBA verification when it is
>> supported by the hardware controller. In case hardware offloading is
>> not supported then we provide APIs to emulate the same. The prominent
>> example of that is NVMe Verify command. We also provide an emulation of
>> the same operation which can be used in case H/W does not support
>> verify. This is still useful when block device is remotely attached e.g.
>> using NVMeOF.
>>
>> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
>> ---
>>   Documentation/ABI/testing/sysfs-block |  14 ++
>>   block/blk-core.c                      |   5 +
>>   block/blk-lib.c                       | 192 ++++++++++++++++++++++++++
>>   block/blk-merge.c                     |  19 +++
>>   block/blk-settings.c                  |  17 +++
>>   block/blk-sysfs.c                     |   8 ++
>>   block/blk-zoned.c                     |   1 +
>>   block/bounce.c                        |   1 +
>>   block/ioctl.c                         |  35 +++++
>>   include/linux/bio.h                   |  10 +-
>>   include/linux/blk_types.h             |   2 +
>>   include/linux/blkdev.h                |  31 +++++
>>   include/uapi/linux/fs.h               |   1 +
>>   13 files changed, 332 insertions(+), 4 deletions(-)
>>
> 
> (skipping to the ioctl part; I didn't see anything obviously weird in
> the block/ changes)
> 

Yes it is pretty straight forward.

>> diff --git a/block/ioctl.c b/block/ioctl.c
>> index d61d652078f4..5e1b3c4660bf 100644
>> --- a/block/ioctl.c
>> +++ b/block/ioctl.c
>> @@ -168,6 +168,39 @@ static int blk_ioctl_zeroout(struct block_device *bdev, fmode_t mode,
>>                        BLKDEV_ZERO_NOUNMAP);
>>   }
>>
>> +static int blk_ioctl_verify(struct block_device *bdev, fmode_t mode,
>> +             unsigned long arg)
>> +{
>> +     uint64_t range[2];
>> +     struct address_space *mapping;
>> +     uint64_t start, end, len;
>> +
>> +     if (!(mode & FMODE_WRITE))
>> +             return -EBADF;
> 
> Why does the fd have to be opened writable?  Isn't this a read test?
> 

Yes this needs to be removed, will fix it in the V1.

>> +
>> +     if (copy_from_user(range, (void __user *)arg, sizeof(range)))
>> +             return -EFAULT;
>> +
>> +     start = range[0];
>> +     len = range[1];
>> +     end = start + len - 1;
>> +
>> +     if (start & 511)
>> +             return -EINVAL;
>> +     if (len & 511)
>> +             return -EINVAL;
>> +     if (end >= (uint64_t)i_size_read(bdev->bd_inode))
>> +             return -EINVAL;
>> +     if (end < start)
>> +             return -EINVAL;
>> +
>> +     /* Invalidate the page cache, including dirty pages */
>> +     mapping = bdev->bd_inode->i_mapping;
>> +     truncate_inode_pages_range(mapping, start, end);
> 
> Why do we need to invalidate the page cache to verify media?  Won't that
> cause data loss if those pages were dirty and about to be flushed?
> 
> --D
> 

Yes, will fix it in the v1.

>> +
>> +     return blkdev_issue_verify(bdev, start >> 9, len >> 9, GFP_KERNEL);
>> +}
>> +

Thanks a lot Derrik for your comments, I'll add fixes to V1.





  reply	other threads:[~2021-11-11  8:01 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 [this message]
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
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=3875c1ba-e70e-baf4-bc3e-d0a7e22a7fc4@nvidia.com \
    --to=chaitanyak@nvidia.com \
    --cc=djwong@kernel.org \
    --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).