All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: fam@euphon.net, kwolf@redhat.com, integration@gluster.org,
	berto@igalia.com, stefanha@redhat.com, qemu-block@nongnu.org,
	pavel.dovgaluk@ispras.ru, sw@weilnetz.de, pl@kamp.de,
	qemu-devel@nongnu.org, jsnow@redhat.com, hreitz@redhat.com,
	kraxel@redhat.com, ronniesahlberg@gmail.com, pbonzini@redhat.com,
	idryomov@gmail.com, philmd@redhat.com, ari@tuxera.com
Subject: Re: [PATCH v6 03/11] block: use int64_t instead of uint64_t in driver read handlers
Date: Fri, 3 Sep 2021 16:30:27 -0500	[thread overview]
Message-ID: <20210903213027.w6axravx5n54odgt@redhat.com> (raw)
In-Reply-To: <20210903102807.27127-4-vsementsov@virtuozzo.com>

On Fri, Sep 03, 2021 at 01:27:59PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> We are generally moving to int64_t for both offset and bytes parameters
> on all io paths.
> 
> Main motivation is realization of 64-bit write_zeroes operation for
> fast zeroing large disk chunks, up to the whole disk.
> 
> We chose signed type, to be consistent with off_t (which is signed) and
> with possibility for signed return type (where negative value means
> error).
> 
> So, convert driver read handlers parameters which are already 64bit to
> signed type.
> 
> While being here, convert also flags parameter to be BdrvRequestFlags.
> 
> Now let's consider all callers. Simple
> 
>   git grep '\->bdrv_\(aio\|co\)_preadv\(_part\)\?'
> 
> shows that's there three callers of driver function:
> 
>  bdrv_driver_preadv() in block/io.c, passes int64_t, checked by
>    bdrv_check_qiov_request() to be non-negative.
> 
>  qcow2_load_vmstate() does bdrv_check_qiov_request().
> 
>  do_perform_cow_read() has uint64_t argument. And a lot of things in
>  qcow2 driver are uint64_t, so converting it is big job. But we must
>  not work with requests that don't satisfy bdrv_check_qiov_request(),
>  so let's just assert it here.
> 
> Still, the functions may be called directly, not only by drv->...
> Let's check:
> 
> git grep '\.bdrv_\(aio\|co\)_preadv\(_part\)\?\s*=' | \
> awk '{print $4}' | sed 's/,//' | sed 's/&//' | sort | uniq | \
> while read func; do git grep "$func(" | \
> grep -v "$func(BlockDriverState"; done
> 
> The only one such caller:
> 
>     QEMUIOVector qiov = QEMU_IOVEC_INIT_BUF(qiov, &data, 1);
>     ...
>     ret = bdrv_replace_test_co_preadv(bs, 0, 1, &qiov, 0);
> 
> in tesTS/unit/test-bdrv-drain.c, and it's OK obviously.

Odd capitalization.

> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---

> +++ b/block/qcow2-cluster.c
> @@ -505,7 +505,19 @@ static int coroutine_fn do_perform_cow_read(BlockDriverState *bs,
>          return -ENOMEDIUM;
>      }
>  
> -    /* Call .bdrv_co_readv() directly instead of using the public block-layer
> +    /*
> +     * We never deal with requests that doesn't satisfy
> +     * bdrv_check_qiov_request(), and aligning requests to clusters never break

never breaks

> +     * this condition. So, do some assertions before calling
> +     * bs->drv->bdrv_co_preadv_part() which has int64_t arguments.
> +     */
> +    assert(src_cluster_offset <= INT64_MAX);
> +    assert(src_cluster_offset + offset_in_cluster <= INT64_MAX);
> +    assert(qiov->size <= INT64_MAX);
> +    bdrv_check_qiov_request(src_cluster_offset + offset_in_cluster, qiov->size,
> +                            qiov, 0, &error_abort);

> +++ b/slirp
> @@ -1 +1 @@
> -Subproject commit a88d9ace234a24ce1c17189642ef9104799425e0
> +Subproject commit 8f43a99191afb47ca3f3c6972f6306209f367ece
> diff --git a/ui/keycodemapdb b/ui/keycodemapdb
> index d21009b1c9..6119e6e19a 160000
> --- a/ui/keycodemapdb
> +++ b/ui/keycodemapdb
> @@ -1 +1 @@
> -Subproject commit d21009b1c9f94b740ea66be8e48a1d8ad8124023
> +Subproject commit 6119e6e19a050df847418de7babe5166779955e4

Oops.  Fix that (or I can do it while staging, if the rest of the
series is okay), and you have:

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2021-09-03 21:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 10:27 [PATCH v6 00/11] 64bit block-layer: part II Vladimir Sementsov-Ogievskiy
2021-09-03 10:27 ` [PATCH v6 01/11] block/io: bring request check to bdrv_co_(read, write)v_vmstate Vladimir Sementsov-Ogievskiy via
2021-09-03 10:27 ` [PATCH v6 02/11] qcow2: check request on vmstate save/load path Vladimir Sementsov-Ogievskiy
2021-09-03 10:27 ` [PATCH v6 03/11] block: use int64_t instead of uint64_t in driver read handlers Vladimir Sementsov-Ogievskiy
2021-09-03 21:30   ` Eric Blake [this message]
2021-09-03 10:28 ` [PATCH v6 04/11] block: use int64_t instead of uint64_t in driver write handlers Vladimir Sementsov-Ogievskiy
2021-09-03 21:34   ` Eric Blake
2021-09-03 10:28 ` [PATCH v6 05/11] block: use int64_t instead of uint64_t in copy_range driver handlers Vladimir Sementsov-Ogievskiy
2021-09-03 10:28 ` [PATCH v6 06/11] block: make BlockLimits::max_pwrite_zeroes 64bit Vladimir Sementsov-Ogievskiy
2021-09-23 19:58   ` Eric Blake
2021-09-03 10:28 ` [PATCH v6 07/11] block: use int64_t instead of int in driver write_zeroes handlers Vladimir Sementsov-Ogievskiy
2021-09-23 20:33   ` Eric Blake
2021-09-23 20:53     ` Eric Blake
2021-09-23 21:50     ` Vladimir Sementsov-Ogievskiy
2021-09-03 10:28 ` [PATCH v6 08/11] block/io: allow 64bit write-zeroes requests Vladimir Sementsov-Ogievskiy
2021-09-03 10:28 ` [PATCH v6 09/11] block: make BlockLimits::max_pdiscard 64bit Vladimir Sementsov-Ogievskiy
2021-09-03 10:28 ` [PATCH v6 10/11] block: use int64_t instead of int in driver discard handlers Vladimir Sementsov-Ogievskiy
2021-09-23 20:58   ` Eric Blake
2021-09-03 10:28 ` [PATCH v6 11/11] block/io: allow 64bit discard requests Vladimir Sementsov-Ogievskiy
2021-09-22  7:52 ` [PATCH v6 00/11] 64bit block-layer: part II Vladimir Sementsov-Ogievskiy
2021-09-22 13:13   ` Eric Blake

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=20210903213027.w6axravx5n54odgt@redhat.com \
    --to=eblake@redhat.com \
    --cc=ari@tuxera.com \
    --cc=berto@igalia.com \
    --cc=fam@euphon.net \
    --cc=hreitz@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=integration@gluster.org \
    --cc=jsnow@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pavel.dovgaluk@ispras.ru \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=sw@weilnetz.de \
    --cc=vsementsov@virtuozzo.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.