From nobody Tue Feb 10 05:10:40 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1507230539442815.7714390243249; Thu, 5 Oct 2017 12:08:59 -0700 (PDT) Received: from localhost ([::1]:41686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0BVs-0003E4-J3 for importer@patchew.org; Thu, 05 Oct 2017 15:08:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0BQY-0007qK-LU for qemu-devel@nongnu.org; Thu, 05 Oct 2017 15:03:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e0BQS-0002IA-Ps for qemu-devel@nongnu.org; Thu, 05 Oct 2017 15:03:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39246) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e0BQN-0002EG-7n; Thu, 05 Oct 2017 15:03:11 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 34EF87E38F; Thu, 5 Oct 2017 19:03:10 +0000 (UTC) Received: from red.redhat.com (ovpn-120-2.rdu2.redhat.com [10.10.120.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id 97DF5173C0; Thu, 5 Oct 2017 19:03:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 34EF87E38F Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eblake@redhat.com From: Eric Blake To: qemu-devel@nongnu.org Date: Thu, 5 Oct 2017 14:02:44 -0500 Message-Id: <20171005190248.5537-3-eblake@redhat.com> In-Reply-To: <20171005190248.5537-1-eblake@redhat.com> References: <20171005190248.5537-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 05 Oct 2017 19:03:10 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v3 2/6] block: Uniform handling of 0-length bdrv_get_block_status() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, Fam Zheng , qemu-block@nongnu.org, jcody@redhat.com, Max Reitz , stefanha@redhat.com, jsnow@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Handle a 0-length block status request up front, with a uniform return value claiming the area is not allocated. Most callers don't pass a length of 0 to bdrv_get_block_status() and friends; but it definitely happens with a 0-length read when copy-on-read is enabled. While we could audit all callers to ensure that they never make a 0-length request, and then assert that fact, it was just as easy to fix things to always report success (as long as the callers are careful to not go into an infinite loop). However, we had inconsistent behavior on whether the status is reported as allocated or defers to the backing layer, depending on what callbacks the driver implements, and possibly wasting quite a few CPU cycles to get to that answer. Consistently reporting unallocated up front doesn't really hurt anything, and makes it easier both for callers (0-length requests now have well-defined behavior) and for drivers (drivers don't have to deal with 0-length requests). Signed-off-by: Eric Blake Reviewed-by: Stefan Hajnoczi --- v3: split into two conditionals [Stefan], simple enough to keep R-b v2: new patch --- block/io.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/block/io.c b/block/io.c index e0f904583f..94f74703b7 100644 --- a/block/io.c +++ b/block/io.c @@ -1777,6 +1777,10 @@ static int64_t coroutine_fn bdrv_co_get_block_status= (BlockDriverState *bs, *pnum =3D 0; return BDRV_BLOCK_EOF; } + if (!nb_sectors) { + *pnum =3D 0; + return 0; + } n =3D total_sectors - sector_num; if (n < nb_sectors) { --=20 2.13.6