From patchwork Mon Nov 20 14:11:40 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Wolf X-Patchwork-Id: 839569 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3ygVzS376yz9s1h for ; Tue, 21 Nov 2017 01:12:35 +1100 (AEDT) Received: from localhost ([::1]:57535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGmoK-0003dL-6D for incoming@patchwork.ozlabs.org; Mon, 20 Nov 2017 09:12:32 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGmnl-0003bm-Oq for qemu-devel@nongnu.org; Mon, 20 Nov 2017 09:11:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGmnk-0004dX-Um for qemu-devel@nongnu.org; Mon, 20 Nov 2017 09:11:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44612) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eGmng-0004Yb-Id; Mon, 20 Nov 2017 09:11:52 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BE4946A7EB; Mon, 20 Nov 2017 14:11:51 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-116-185.ams2.redhat.com [10.36.116.185]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9B8334F9EF; Mon, 20 Nov 2017 14:11:49 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Mon, 20 Nov 2017 15:11:40 +0100 Message-Id: <20171120141141.24626-2-kwolf@redhat.com> In-Reply-To: <20171120141141.24626-1-kwolf@redhat.com> References: <20171120141141.24626-1-kwolf@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 20 Nov 2017 14:11:51 +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.11 1/2] block: Don't use BLK_PERM_CONSISTENT_READ for format probing 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, famz@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" For format probing, we don't really care whether all of the image content is consistent. The only thing we're looking at is the image header, and specifically the magic numbers that are expected to never change, no matter how inconsistent the guest visible disk content is. Therefore, don't request BLK_PERM_CONSISTENT_READ. This allows to use format probing, e.g. in the context of 'qemu-img info', even while the guest visible data in the image is inconsistent during a running block job. Signed-off-by: Kevin Wolf --- block.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/block.c b/block.c index 6c8ef98dfa..68b724206d 100644 --- a/block.c +++ b/block.c @@ -2579,7 +2579,10 @@ static BlockDriverState *bdrv_open_inherit(const char *filename, goto fail; } if (file_bs != NULL) { - file = blk_new(BLK_PERM_CONSISTENT_READ, BLK_PERM_ALL); + /* Not requesting BLK_PERM_CONSISTENT_READ because we're only + * looking at the header to guess the image format. This works even + * in cases where a guest would not see a consistent state. */ + file = blk_new(0, BLK_PERM_ALL); blk_insert_bs(file, file_bs, &local_err); bdrv_unref(file_bs); if (local_err) { From patchwork Mon Nov 20 14:11:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Wolf X-Patchwork-Id: 839577 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3ygW1L2SLBz9ryv for ; Tue, 21 Nov 2017 01:14:14 +1100 (AEDT) Received: from localhost ([::1]:57542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGmpw-0004vR-Fm for incoming@patchwork.ozlabs.org; Mon, 20 Nov 2017 09:14:12 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eGmnm-0003bn-10 for qemu-devel@nongnu.org; Mon, 20 Nov 2017 09:12:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eGmnl-0004de-1u for qemu-devel@nongnu.org; Mon, 20 Nov 2017 09:11:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46110) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eGmni-0004bX-Mi; Mon, 20 Nov 2017 09:11:54 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5A62C0587FF; Mon, 20 Nov 2017 14:11:53 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-116-185.ams2.redhat.com [10.36.116.185]) by smtp.corp.redhat.com (Postfix) with ESMTP id 163AA4FA20; Mon, 20 Nov 2017 14:11:51 +0000 (UTC) From: Kevin Wolf To: qemu-block@nongnu.org Date: Mon, 20 Nov 2017 15:11:41 +0100 Message-Id: <20171120141141.24626-3-kwolf@redhat.com> In-Reply-To: <20171120141141.24626-1-kwolf@redhat.com> References: <20171120141141.24626-1-kwolf@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 20 Nov 2017 14:11:53 +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.11 2/2] block: Don't request I/O permission with BDRV_O_NO_IO 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, famz@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 'qemu-img info' makes sense even when BLK_PERM_CONSISTENT_READ cannot be granted because of a block job in a running qemu process. It already sets BDRV_O_NO_IO to indicate that it doesn't access the guest visible data at all. Check the BDRV_O_NO_IO flags in blk_new_open(), so that I/O related permissions are not unnecessarily requested and 'qemu-img info' can work even if BLK_PERM_CONSISTENT_READ cannot be granted. Signed-off-by: Kevin Wolf Reviewed-by: Alberto Garcia --- block/block-backend.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/block/block-backend.c b/block/block-backend.c index 5836cb3087..baef8e7abc 100644 --- a/block/block-backend.c +++ b/block/block-backend.c @@ -299,7 +299,7 @@ BlockBackend *blk_new_open(const char *filename, const char *reference, { BlockBackend *blk; BlockDriverState *bs; - uint64_t perm; + uint64_t perm = 0; /* blk_new_open() is mainly used in .bdrv_create implementations and the * tools where sharing isn't a concern because the BDS stays private, so we @@ -309,9 +309,11 @@ BlockBackend *blk_new_open(const char *filename, const char *reference, * caller of blk_new_open() doesn't make use of the permissions, but they * shouldn't hurt either. We can still share everything here because the * guest devices will add their own blockers if they can't share. */ - perm = BLK_PERM_CONSISTENT_READ; - if (flags & BDRV_O_RDWR) { - perm |= BLK_PERM_WRITE; + if ((flags & BDRV_O_NO_IO) == 0) { + perm |= BLK_PERM_CONSISTENT_READ; + if (flags & BDRV_O_RDWR) { + perm |= BLK_PERM_WRITE; + } } if (flags & BDRV_O_RESIZE) { perm |= BLK_PERM_RESIZE;