From nobody Tue Apr 30 09:29:30 2024 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.zoho.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 149192233052549.55093976006242; Tue, 11 Apr 2017 07:52:10 -0700 (PDT) Received: from localhost ([::1]:39628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cxx9M-0000L8-Vw for importer@patchew.org; Tue, 11 Apr 2017 10:52:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cxx8c-0008Rh-RE for qemu-devel@nongnu.org; Tue, 11 Apr 2017 10:51:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cxx8c-0007jr-2g for qemu-devel@nongnu.org; Tue, 11 Apr 2017 10:51:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55426) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cxx8X-0007g2-FB; Tue, 11 Apr 2017 10:51:17 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5106775EBA; Tue, 11 Apr 2017 14:51:16 +0000 (UTC) Received: from localhost (ovpn-204-201.brq.redhat.com [10.40.204.201]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5A92E18EE9; Tue, 11 Apr 2017 14:50:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5106775EBA 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=pass smtp.mailfrom=mreitz@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5106775EBA From: Max Reitz To: qemu-block@nongnu.org Date: Tue, 11 Apr 2017 16:50:50 +0200 Message-Id: <20170411145050.31290-1-mreitz@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 11 Apr 2017 14:51:16 +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 for-2.9?] block/io: Comment out permission assertions 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: Kevin Wolf , Laurent Vivier , Fam Zheng , qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi 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" In case of block migration, there may be writes to BlockBackends that do not have the write permission taken. Before this issue is fixed (which is not going to happen in 2.9), we therefore cannot assert that this is the case. Suggested-by: Kevin Wolf Signed-off-by: Max Reitz Reviewed-by: Kevin Wolf Tested-by: Kevin Wolf Tested-by: Laurent Vivier --- block.c | 6 +++++- block/io.c | 12 ++++++++++-- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/block.c b/block.c index 086a12df97..1fbbb8d606 100644 --- a/block.c +++ b/block.c @@ -3274,7 +3274,11 @@ int bdrv_truncate(BdrvChild *child, int64_t offset) BlockDriver *drv =3D bs->drv; int ret; =20 - assert(child->perm & BLK_PERM_RESIZE); + /* FIXME: Some format block drivers use this function instead of impli= citly + * growing their file by writing beyond its end. + * See bdrv_aligned_pwritev() for an explanation why we current= ly + * cannot assert this permission in that case. */ + // assert(child->perm & BLK_PERM_RESIZE); =20 if (!drv) return -ENOMEDIUM; diff --git a/block/io.c b/block/io.c index bae6947032..8706bfa578 100644 --- a/block/io.c +++ b/block/io.c @@ -1345,8 +1345,16 @@ static int coroutine_fn bdrv_aligned_pwritev(BdrvChi= ld *child, assert(!waited || !req->serialising); assert(req->overlap_offset <=3D offset); assert(offset + bytes <=3D req->overlap_offset + req->overlap_bytes); - assert(child->perm & BLK_PERM_WRITE); - assert(end_sector <=3D bs->total_sectors || child->perm & BLK_PERM_RES= IZE); + /* FIXME: Block migration uses the BlockBackend of the guest device at= a + * point when it has not yet taken write permissions. This will= be + * fixed by a future patch, but for now we have to bypass this + * assertion for block migration to work. */ + // assert(child->perm & BLK_PERM_WRITE); + /* FIXME: Because of the above, we also cannot guarantee that all form= at + * BDS take the BLK_PERM_RESIZE permission on their file BDS, s= ince + * they are not obligated to do so if they do not have any pare= nt + * that has taken the permission to write to them. */ + // assert(end_sector <=3D bs->total_sectors || child->perm & BLK_PERM_= RESIZE); =20 ret =3D notifier_with_return_list_notify(&bs->before_write_notifiers, = req); =20 --=20 2.12.2