From nobody Thu Dec 18 19:34:27 2025 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; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1526400802175188.0111094999795; Tue, 15 May 2018 09:13:22 -0700 (PDT) Received: from localhost ([::1]:44768 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fIcZl-0008IS-7T for importer@patchew.org; Tue, 15 May 2018 12:13:21 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fIc4l-00075V-JZ for qemu-devel@nongnu.org; Tue, 15 May 2018 11:41:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fIc4k-0001tC-CP for qemu-devel@nongnu.org; Tue, 15 May 2018 11:41:19 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:36682 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fIc4d-0001jv-7w; Tue, 15 May 2018 11:41:11 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C57EE40201A4; Tue, 15 May 2018 15:41:10 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-117-164.ams2.redhat.com [10.36.117.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 242842026E0E; Tue, 15 May 2018 15:41:10 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Tue, 15 May 2018 17:40:29 +0200 Message-Id: <20180515154033.19899-34-kwolf@redhat.com> In-Reply-To: <20180515154033.19899-1-kwolf@redhat.com> References: <20180515154033.19899-1-kwolf@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 15 May 2018 15:41:10 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 15 May 2018 15:41:10 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'kwolf@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PULL 33/37] qemu-img: Check post-truncation size 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, qemu-devel@nongnu.org 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" From: Max Reitz Some block drivers (iscsi and file-posix when dealing with device files) do not actually support truncation, even though they provide a .bdrv_truncate() method and will happily return success when providing a new size that does not exceed the current size. This is because these drivers expect the user to resize the image outside of qemu and then provide qemu with that information through the block_resize command (compare cb1b83e740384b4e0d950f3d7c81c02b8ce86c2e). Of course, anyone using qemu-img resize will find that behavior useless. So we should check the actual size of the image after the supposedly successful truncation took place, emit an error if nothing changed and emit a warning if the target size was not met. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=3D1523065 Signed-off-by: Max Reitz Message-id: 20180421163957.29872-1-mreitz@redhat.com Reviewed-by: Stefan Hajnoczi Signed-off-by: Max Reitz --- qemu-img.c | 39 +++++++++++++++++++++++++++++++++++---- 1 file changed, 35 insertions(+), 4 deletions(-) diff --git a/qemu-img.c b/qemu-img.c index ea62d2d61e..62b29e7feb 100644 --- a/qemu-img.c +++ b/qemu-img.c @@ -3381,7 +3381,7 @@ static int img_resize(int argc, char **argv) Error *err =3D NULL; int c, ret, relative; const char *filename, *fmt, *size; - int64_t n, total_size, current_size; + int64_t n, total_size, current_size, new_size; bool quiet =3D false; BlockBackend *blk =3D NULL; PreallocMode prealloc =3D PREALLOC_MODE_OFF; @@ -3557,11 +3557,42 @@ static int img_resize(int argc, char **argv) } =20 ret =3D blk_truncate(blk, total_size, prealloc, &err); - if (!ret) { - qprintf(quiet, "Image resized.\n"); - } else { + if (ret < 0) { error_report_err(err); + goto out; + } + + new_size =3D blk_getlength(blk); + if (new_size < 0) { + error_report("Failed to verify truncated image length: %s", + strerror(-new_size)); + ret =3D -1; + goto out; } + + /* Some block drivers implement a truncation method, but only so + * the user can cause qemu to refresh the image's size from disk. + * The idea is that the user resizes the image outside of qemu and + * then invokes block_resize to inform qemu about it. + * (This includes iscsi and file-posix for device files.) + * Of course, that is not the behavior someone invoking + * qemu-img resize would find useful, so we catch that behavior + * here and tell the user. */ + if (new_size !=3D total_size && new_size =3D=3D current_size) { + error_report("Image was not resized; resizing may not be supported= " + "for this image"); + ret =3D -1; + goto out; + } + + if (new_size !=3D total_size) { + warn_report("Image should have been resized to %" PRIi64 + " bytes, but was resized to %" PRIi64 " bytes", + total_size, new_size); + } + + qprintf(quiet, "Image resized.\n"); + out: blk_unref(blk); if (ret) { --=20 2.13.6