From nobody Thu Dec 18 13:19:10 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 1530281834744639.3875772435426; Fri, 29 Jun 2018 07:17:14 -0700 (PDT) Received: from localhost ([::1]:42487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYuD3-0001Pg-Vt for importer@patchew.org; Fri, 29 Jun 2018 10:17:14 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYu6Q-0003ss-5e for qemu-devel@nongnu.org; Fri, 29 Jun 2018 10:10:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYu6O-0003rL-H6 for qemu-devel@nongnu.org; Fri, 29 Jun 2018 10:10:21 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:51346 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 1fYu6J-0003gP-1y; Fri, 29 Jun 2018 10:10:15 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6642C401EF1D; Fri, 29 Jun 2018 14:10:14 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-116-232.ams2.redhat.com [10.36.116.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id 92A021102E29; Fri, 29 Jun 2018 14:10:13 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Fri, 29 Jun 2018 16:09:40 +0200 Message-Id: <20180629140959.6690-11-kwolf@redhat.com> In-Reply-To: <20180629140959.6690-1-kwolf@redhat.com> References: <20180629140959.6690-1-kwolf@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 29 Jun 2018 14:10:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 29 Jun 2018 14:10:14 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.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 10/29] block: Use tracked request for truncate 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, peter.maydell@linaro.org, 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" When growing an image, block drivers (especially protocol drivers) may initialise the newly added area. I/O requests to the same area need to wait for this initialisation to be completed so that data writes don't get overwritten and reads don't read uninitialised data. To avoid overhead in the fast I/O path by adding new locking in the protocol drivers and to restrict the impact to requests that actually touch the new area, reuse the existing tracked request infrastructure in block/io.c and mark all discard requests as serialising. With this change, it is safe for protocol drivers to make .bdrv_co_truncate actually asynchronous. Signed-off-by: Kevin Wolf Reviewed-by: Stefan Hajnoczi --- include/block/block_int.h | 1 + block/io.c | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/include/block/block_int.h b/include/block/block_int.h index 740166a996..af71b414be 100644 --- a/include/block/block_int.h +++ b/include/block/block_int.h @@ -63,6 +63,7 @@ enum BdrvTrackedRequestType { BDRV_TRACKED_READ, BDRV_TRACKED_WRITE, BDRV_TRACKED_DISCARD, + BDRV_TRACKED_TRUNCATE, }; =20 typedef struct BdrvTrackedRequest { diff --git a/block/io.c b/block/io.c index 7e87a42b8e..01a3c4eac5 100644 --- a/block/io.c +++ b/block/io.c @@ -3039,6 +3039,8 @@ int coroutine_fn bdrv_co_truncate(BdrvChild *child, i= nt64_t offset, { BlockDriverState *bs =3D child->bs; BlockDriver *drv =3D bs->drv; + BdrvTrackedRequest req; + int64_t old_size, new_bytes; int ret; =20 assert(child->perm & BLK_PERM_RESIZE); @@ -3053,7 +3055,28 @@ int coroutine_fn bdrv_co_truncate(BdrvChild *child, = int64_t offset, return -EINVAL; } =20 + old_size =3D bdrv_getlength(bs); + if (old_size < 0) { + error_setg_errno(errp, -old_size, "Failed to get old image size"); + return old_size; + } + + if (offset > old_size) { + new_bytes =3D offset - old_size; + } else { + new_bytes =3D 0; + } + bdrv_inc_in_flight(bs); + tracked_request_begin(&req, bs, offset, new_bytes, BDRV_TRACKED_TRUNCA= TE); + + /* If we are growing the image and potentially using preallocation for= the + * new area, we need to make sure that no write requests are made to it + * concurrently or they might be overwritten by preallocation. */ + if (new_bytes) { + mark_request_serialising(&req, 1); + wait_serialising_requests(&req); + } =20 if (!drv->bdrv_co_truncate) { if (bs->file && drv->is_filter) { @@ -3087,7 +3110,9 @@ int coroutine_fn bdrv_co_truncate(BdrvChild *child, i= nt64_t offset, atomic_inc(&bs->write_gen); =20 out: + tracked_request_end(&req); bdrv_dec_in_flight(bs); + return ret; } =20 --=20 2.13.6