[{"id":1775781,"web_url":"http://patchwork.ozlabs.org/comment/1775781/","msgid":"","list_archive_url":null,"date":"2017-09-26T18:51:38","subject":"Re: [Qemu-devel] [PATCH v4 03/23] block: Make\n\tbdrv_round_to_clusters() signature more useful","submitter":{"id":64343,"url":"http://patchwork.ozlabs.org/api/people/64343/","name":"John Snow","email":"jsnow@redhat.com"},"content":"On 09/13/2017 12:03 PM, Eric Blake wrote:\n> In the process of converting sector-based interfaces to bytes,\n> I'm finding it easier to represent a byte count as a 64-bit\n> integer at the block layer (even if we are internally capped\n> by SIZE_MAX or even INT_MAX for individual transactions, it's\n> still nicer to not have to worry about truncation/overflow\n> issues on as many variables). Update the signature of\n> bdrv_round_to_clusters() to uniformly use int64_t, matching\n> the signature already chosen for bdrv_is_allocated and the\n> fact that off_t is also a signed type, then adjust clients\n> according to the required fallout.\n> \n> Signed-off-by: Eric Blake \n> Reviewed-by: Fam Zheng \n> \n> ---\n> v4: only context changes\n> v3: no change\n> v2: fix commit message [John], rebase to earlier changes, including\n> mirror_clip_bytes() signature update\n> ---\n> include/block/block.h | 4 ++--\n> block/io.c | 7 ++++---\n> block/mirror.c | 7 +++----\n> block/trace-events | 2 +-\n> 4 files changed, 10 insertions(+), 10 deletions(-)\n> \n> diff --git a/include/block/block.h b/include/block/block.h\n> index 2ad18775af..bb3b95d491 100644\n> --- a/include/block/block.h\n> +++ b/include/block/block.h\n> @@ -475,9 +475,9 @@ int bdrv_get_flags(BlockDriverState *bs);\n> int bdrv_get_info(BlockDriverState *bs, BlockDriverInfo *bdi);\n> ImageInfoSpecific *bdrv_get_specific_info(BlockDriverState *bs);\n> void bdrv_round_to_clusters(BlockDriverState *bs,\n> - int64_t offset, unsigned int bytes,\n> + int64_t offset, int64_t bytes,\n> int64_t *cluster_offset,\n> - unsigned int *cluster_bytes);\n> + int64_t *cluster_bytes);\n> \n> const char *bdrv_get_encrypted_filename(BlockDriverState *bs);\n> void bdrv_get_backing_filename(BlockDriverState *bs,\n> diff --git a/block/io.c b/block/io.c\n> index 6509c804d4..b362b46e3d 100644\n> --- a/block/io.c\n> +++ b/block/io.c\n> @@ -446,9 +446,9 @@ static void mark_request_serialising(BdrvTrackedRequest *req, uint64_t align)\n> * Round a region to cluster boundaries\n> */\n> void bdrv_round_to_clusters(BlockDriverState *bs,\n> - int64_t offset, unsigned int bytes,\n> + int64_t offset, int64_t bytes,\n> int64_t *cluster_offset,\n> - unsigned int *cluster_bytes)\n> + int64_t *cluster_bytes)\n> {\n> BlockDriverInfo bdi;\n> \n> @@ -946,7 +946,7 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,\n> struct iovec iov;\n> QEMUIOVector bounce_qiov;\n> int64_t cluster_offset;\n> - unsigned int cluster_bytes;\n> + int64_t cluster_bytes;\n> size_t skip_bytes;\n> int ret;\n> \n> @@ -967,6 +967,7 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,\n> trace_bdrv_co_do_copy_on_readv(bs, offset, bytes,\n> cluster_offset, cluster_bytes);\n> \n> + assert(cluster_bytes < SIZE_MAX);\n\nlater in this function, is there any real or imagined risk of\ncluster_bytes exceeding INT_MAX when it's passed to\nbdrv_co_do_pwrite_zeroes?\n\n> iov.iov_len = cluster_bytes;\n> iov.iov_base = bounce_buffer = qemu_try_blockalign(bs, iov.iov_len);\n> if (bounce_buffer == NULL) {\n> diff --git a/block/mirror.c b/block/mirror.c\n> index 032cfe91fa..67f45cec4e 100644\n> --- a/block/mirror.c\n> +++ b/block/mirror.c\n> @@ -190,10 +190,9 @@ static int mirror_cow_align(MirrorBlockJob *s, int64_t *offset,\n> bool need_cow;\n> int ret = 0;\n> int64_t align_offset = *offset;\n> - unsigned int align_bytes = *bytes;\n> + int64_t align_bytes = *bytes;\n> int max_bytes = s->granularity * s->max_iov;\n> \n> - assert(*bytes < INT_MAX);\n> need_cow = !test_bit(*offset / s->granularity, s->cow_bitmap);\n> need_cow |= !test_bit((*offset + *bytes - 1) / s->granularity,\n> s->cow_bitmap);\n> @@ -388,7 +387,7 @@ static uint64_t coroutine_fn mirror_iteration(MirrorBlockJob *s)\n> while (nb_chunks > 0 && offset < s->bdev_length) {\n> int64_t ret;\n> int io_sectors;\n> - unsigned int io_bytes;\n> + int64_t io_bytes;\n> int64_t io_bytes_acct;\n> enum MirrorMethod {\n> MIRROR_METHOD_COPY,\n> @@ -413,7 +412,7 @@ static uint64_t coroutine_fn mirror_iteration(MirrorBlockJob *s)\n> io_bytes = s->granularity;\n> } else if (ret >= 0 && !(ret & BDRV_BLOCK_DATA)) {\n> int64_t target_offset;\n> - unsigned int target_bytes;\n> + int64_t target_bytes;\n> bdrv_round_to_clusters(blk_bs(s->target), offset, io_bytes,\n> &target_offset, &target_bytes);\n> if (target_offset == offset &&\n> diff --git a/block/trace-events b/block/trace-events\n> index 25dd5a3026..4c6586f156 100644\n> --- a/block/trace-events\n> +++ b/block/trace-events\n> @@ -12,7 +12,7 @@ blk_co_pwritev(void *blk, void *bs, int64_t offset, unsigned int bytes, int flag\n> bdrv_co_preadv(void *bs, int64_t offset, int64_t nbytes, unsigned int flags) \"bs %p offset %\"PRId64\" nbytes %\"PRId64\" flags 0x%x\"\n> bdrv_co_pwritev(void *bs, int64_t offset, int64_t nbytes, unsigned int flags) \"bs %p offset %\"PRId64\" nbytes %\"PRId64\" flags 0x%x\"\n> bdrv_co_pwrite_zeroes(void *bs, int64_t offset, int count, int flags) \"bs %p offset %\"PRId64\" count %d flags 0x%x\"\n> -bdrv_co_do_copy_on_readv(void *bs, int64_t offset, unsigned int bytes, int64_t cluster_offset, unsigned int cluster_bytes) \"bs %p offset %\"PRId64\" bytes %u cluster_offset %\"PRId64\" cluster_bytes %u\"\n> +bdrv_co_do_copy_on_readv(void *bs, int64_t offset, int64_t bytes, int64_t cluster_offset, unsigned int cluster_bytes) \"bs %p offset %\"PRId64\" bytes %\"PRId64\" cluster_offset %\"PRId64\" cluster_bytes %u\"\n> \n> # block/stream.c\n> stream_one_iteration(void *s, int64_t offset, uint64_t bytes, int is_allocated) \"s %p offset %\" PRId64 \" bytes %\" PRIu64 \" is_allocated %d\"\n> \n\nEverything else looks obviously correct to me.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx08.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jsnow@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1qnr6nrSz9tXK\n\tfor ;\n\tWed, 27 Sep 2017 04:52:32 +1000 (AEST)","from localhost ([::1]:50750 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwuy5-00062L-NT\n\tfor incoming@patchwork.ozlabs.org; Tue, 26 Sep 2017 14:52:29 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:51074)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwuxW-00060N-2A\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 14:51:55 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwuxU-0003wW-Le\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 14:51:54 -0400","from mx1.redhat.com ([209.132.183.28]:56636)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dwuxP-0003tH-Nk; Tue, 26 Sep 2017 14:51:47 -0400","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id F1C50C0587EE;\n\tTue, 26 Sep 2017 18:51:45 +0000 (UTC)","from [10.18.17.130] (dhcp-17-130.bos.redhat.com [10.18.17.130])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 29998779E4;\n\tTue, 26 Sep 2017 18:51:38 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com F1C50C0587EE","To":"Eric Blake , qemu-devel@nongnu.org","References":"<20170913160333.23622-1-eblake@redhat.com>\n\t<20170913160333.23622-4-eblake@redhat.com>","From":"John Snow ","Message-ID":"","Date":"Tue, 26 Sep 2017 14:51:38 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170913160333.23622-4-eblake@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.32]);\n\tTue, 26 Sep 2017 18:51:46 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v4 03/23] block: Make\n\tbdrv_round_to_clusters() signature more useful","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org,\n\tJeff Cody , Max Reitz ,\n\tStefan Hajnoczi ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1775799,"web_url":"http://patchwork.ozlabs.org/comment/1775799/","msgid":"<87c590cd-e35e-81a7-c1ea-0efccdeed6ab@redhat.com>","list_archive_url":null,"date":"2017-09-26T19:18:54","subject":"Re: [Qemu-devel] [PATCH v4 03/23] block: Make\n\tbdrv_round_to_clusters() signature more useful","submitter":{"id":6591,"url":"http://patchwork.ozlabs.org/api/people/6591/","name":"Eric Blake","email":"eblake@redhat.com"},"content":"On 09/26/2017 01:51 PM, John Snow wrote:\n> \n> \n> On 09/13/2017 12:03 PM, Eric Blake wrote:\n>> In the process of converting sector-based interfaces to bytes,\n>> I'm finding it easier to represent a byte count as a 64-bit\n>> integer at the block layer (even if we are internally capped\n>> by SIZE_MAX or even INT_MAX for individual transactions, it's\n>> still nicer to not have to worry about truncation/overflow\n>> issues on as many variables). Update the signature of\n>> bdrv_round_to_clusters() to uniformly use int64_t, matching\n>> the signature already chosen for bdrv_is_allocated and the\n>> fact that off_t is also a signed type, then adjust clients\n>> according to the required fallout.\n>>\n>> Signed-off-by: Eric Blake \n>> Reviewed-by: Fam Zheng \n>>\n\n>> @@ -946,7 +946,7 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,\n>> struct iovec iov;\n>> QEMUIOVector bounce_qiov;\n>> int64_t cluster_offset;\n>> - unsigned int cluster_bytes;\n>> + int64_t cluster_bytes;\n>> size_t skip_bytes;\n>> int ret;\n>>\n>> @@ -967,6 +967,7 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,\n>> trace_bdrv_co_do_copy_on_readv(bs, offset, bytes,\n>> cluster_offset, cluster_bytes);\n>>\n>> + assert(cluster_bytes < SIZE_MAX);\n> \n> later in this function, is there any real or imagined risk of\n> cluster_bytes exceeding INT_MAX when it's passed to\n> bdrv_co_do_pwrite_zeroes?\n> \n>> iov.iov_len = cluster_bytes;\n\ncluster_bytes is the input 'unsigned int bytes' rounded out to cluster\nboundaries, but where we know 'bytes <= BDRV_REQUEST_MAX_BYTES' (which\nis 2^31 - 511). Still, I guess you are right that rounding to a cluster\nsize could produce a larger value of exactly 2^31 (bigger than INT_MAX,\nbut still fits in 32-bit unsigned int, so my assert was to make sure\nthat truncating 64 bits to size_t iov.iov_len still works on 32-bit\nplatforms).\n\nIn theory, I don't think we ever attempt an unaligned operation near\n2^31 that would round up to INT_MAX overflow (if we can, that's a\npre-existing bug that should be fixed separately).\n\nShould I tighten the assertion to assert(cluster_bytes <=\nBDRV_REQUEST_MAX_BYTES), then see if I can come up with a case where we\ncan violate that?\n\n> Everything else looks obviously correct to me.\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx03.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=eblake@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1rP961zrz9t4X\n\tfor ;\n\tWed, 27 Sep 2017 05:19:41 +1000 (AEST)","from localhost ([::1]:50842 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwvOL-0006v6-2J\n\tfor incoming@patchwork.ozlabs.org; Tue, 26 Sep 2017 15:19:37 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:59026)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwvNv-0006tc-7F\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 15:19:12 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwvNu-00087L-2x\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 15:19:11 -0400","from mx1.redhat.com ([209.132.183.28]:59888)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dwvNo-00083g-Fj; Tue, 26 Sep 2017 15:19:04 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 5E2187E425;\n\tTue, 26 Sep 2017 19:19:03 +0000 (UTC)","from [10.10.124.97] (ovpn-124-97.rdu2.redhat.com [10.10.124.97])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 3D0FB60841;\n\tTue, 26 Sep 2017 19:18:55 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 5E2187E425","To":"John Snow , qemu-devel@nongnu.org","References":"<20170913160333.23622-1-eblake@redhat.com>\n\t<20170913160333.23622-4-eblake@redhat.com>\n\t","From":"Eric Blake ","Openpgp":"url=http://people.redhat.com/eblake/eblake.gpg","Organization":"Red Hat, Inc.","Message-ID":"<87c590cd-e35e-81a7-c1ea-0efccdeed6ab@redhat.com>","Date":"Tue, 26 Sep 2017 14:18:54 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"AM8C7SvK5J9fMGdDORGqxjQiXcchKNAQO\"","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.27]);\n\tTue, 26 Sep 2017 19:19:03 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","X-Content-Filtered-By":"Mailman/MimeDel 2.1.21","Subject":"Re: [Qemu-devel] [PATCH v4 03/23] block: Make\n\tbdrv_round_to_clusters() signature more useful","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org,\n\tJeff Cody , Max Reitz ,\n\tStefan Hajnoczi ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1775807,"web_url":"http://patchwork.ozlabs.org/comment/1775807/","msgid":"","list_archive_url":null,"date":"2017-09-26T19:29:11","subject":"Re: [Qemu-devel] [PATCH v4 03/23] block: Make\n\tbdrv_round_to_clusters() signature more useful","submitter":{"id":64343,"url":"http://patchwork.ozlabs.org/api/people/64343/","name":"John Snow","email":"jsnow@redhat.com"},"content":"On 09/26/2017 03:18 PM, Eric Blake wrote:\n> On 09/26/2017 01:51 PM, John Snow wrote:\n>>\n>>\n>> On 09/13/2017 12:03 PM, Eric Blake wrote:\n>>> In the process of converting sector-based interfaces to bytes,\n>>> I'm finding it easier to represent a byte count as a 64-bit\n>>> integer at the block layer (even if we are internally capped\n>>> by SIZE_MAX or even INT_MAX for individual transactions, it's\n>>> still nicer to not have to worry about truncation/overflow\n>>> issues on as many variables). Update the signature of\n>>> bdrv_round_to_clusters() to uniformly use int64_t, matching\n>>> the signature already chosen for bdrv_is_allocated and the\n>>> fact that off_t is also a signed type, then adjust clients\n>>> according to the required fallout.\n>>>\n>>> Signed-off-by: Eric Blake \n>>> Reviewed-by: Fam Zheng \n>>>\n> \n>>> @@ -946,7 +946,7 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,\n>>> struct iovec iov;\n>>> QEMUIOVector bounce_qiov;\n>>> int64_t cluster_offset;\n>>> - unsigned int cluster_bytes;\n>>> + int64_t cluster_bytes;\n>>> size_t skip_bytes;\n>>> int ret;\n>>>\n>>> @@ -967,6 +967,7 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,\n>>> trace_bdrv_co_do_copy_on_readv(bs, offset, bytes,\n>>> cluster_offset, cluster_bytes);\n>>>\n>>> + assert(cluster_bytes < SIZE_MAX);\n>>\n>> later in this function, is there any real or imagined risk of\n>> cluster_bytes exceeding INT_MAX when it's passed to\n>> bdrv_co_do_pwrite_zeroes?\n>>\n>>> iov.iov_len = cluster_bytes;\n> \n> cluster_bytes is the input 'unsigned int bytes' rounded out to cluster\n\nAh, yes, we're probably not going to exceed that, you're right.\n\n> boundaries, but where we know 'bytes <= BDRV_REQUEST_MAX_BYTES' (which\n> is 2^31 - 511). Still, I guess you are right that rounding to a cluster\n> size could produce a larger value of exactly 2^31 (bigger than INT_MAX,\n> but still fits in 32-bit unsigned int, so my assert was to make sure\n> that truncating 64 bits to size_t iov.iov_len still works on 32-bit\n> platforms).\n> \n> In theory, I don't think we ever attempt an unaligned operation near\n> 2^31 that would round up to INT_MAX overflow (if we can, that's a\n> pre-existing bug that should be fixed separately).\n> \n> Should I tighten the assertion to assert(cluster_bytes <=\n> BDRV_REQUEST_MAX_BYTES), then see if I can come up with a case where we\n> can violate that?\n> \n\n*Only* if you think it's worth your time. You'd know better than me at\nthis point if this is remotely possible or not. Just a simple width\ncheck that caught my eye.\n\n(Gotta prove to everyone I'm reading these, right? :p)\n\n>> Everything else looks obviously correct to me.\n>>\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx09.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=jsnow@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1rd61pRNz9t3F\n\tfor ;\n\tWed, 27 Sep 2017 05:30:02 +1000 (AEST)","from localhost ([::1]:50873 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwvYO-0001Mk-Ba\n\tfor incoming@patchwork.ozlabs.org; Tue, 26 Sep 2017 15:30:00 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:33502)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwvXn-0001IO-Ul\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 15:29:25 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwvXm-0004Oj-V6\n\tfor qemu-devel@nongnu.org; Tue, 26 Sep 2017 15:29:23 -0400","from mx1.redhat.com ([209.132.183.28]:33344)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dwvXh-0004M1-IB; Tue, 26 Sep 2017 15:29:17 -0400","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 8092E4A6EB;\n\tTue, 26 Sep 2017 19:29:16 +0000 (UTC)","from [10.18.17.130] (dhcp-17-130.bos.redhat.com [10.18.17.130])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 8FA875E279;\n\tTue, 26 Sep 2017 19:29:11 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 8092E4A6EB","To":"Eric Blake , qemu-devel@nongnu.org","References":"<20170913160333.23622-1-eblake@redhat.com>\n\t<20170913160333.23622-4-eblake@redhat.com>\n\t\n\t<87c590cd-e35e-81a7-c1ea-0efccdeed6ab@redhat.com>","From":"John Snow ","Message-ID":"","Date":"Tue, 26 Sep 2017 15:29:11 -0400","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<87c590cd-e35e-81a7-c1ea-0efccdeed6ab@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.38]);\n\tTue, 26 Sep 2017 19:29:16 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH v4 03/23] block: Make\n\tbdrv_round_to_clusters() signature more useful","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"kwolf@redhat.com, famz@redhat.com, qemu-block@nongnu.org,\n\tJeff Cody , Max Reitz ,\n\tStefan Hajnoczi ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]