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.
next prev parent 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).