From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmiSN-0006oM-Th for qemu-devel@nongnu.org; Tue, 20 May 2014 07:43:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmiSI-0000h8-NP for qemu-devel@nongnu.org; Tue, 20 May 2014 07:43:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmiSI-0000gl-F2 for qemu-devel@nongnu.org; Tue, 20 May 2014 07:43:38 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4KBhbAJ007022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 May 2014 07:43:38 -0400 Date: Tue, 20 May 2014 07:43:34 -0400 From: Jeff Cody Message-ID: <20140520114334.GA5292@localhost.localdomain> References: <1400565880-13409-1-git-send-email-famz@redhat.com> <1400565880-13409-5-git-send-email-famz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1400565880-13409-5-git-send-email-famz@redhat.com> Subject: Re: [Qemu-devel] [PATCH v20 04/15] block: Move op_blocker check from block_job_create to its caller List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: kwolf@redhat.com, armbru@redhat.com, hbrock@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, imain@redhat.com, stefanha@redhat.com, pbonzini@redhat.com On Tue, May 20, 2014 at 02:04:29PM +0800, Fam Zheng wrote: > It makes no sense to check for "any" blocker on bs, we are here only > because of the mechanical conversion from in_use to op_blockers. Remove > it now, and let the callers check specific operation types. Backup and > mirror already have it, add checker to stream and commit. > > Signed-off-by: Fam Zheng > Reviewed-by: Benoit Canet > Reviewed-by: Jeff Cody > --- > blockdev.c | 8 ++++++++ > blockjob.c | 2 +- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/blockdev.c b/blockdev.c > index 5d950fa..21fc55b 100644 > --- a/blockdev.c > +++ b/blockdev.c > @@ -1850,6 +1850,10 @@ void qmp_block_stream(const char *device, bool has_base, > return; > } > > + if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_STREAM, errp)) { > + return; > + } > + > if (base) { > base_bs = bdrv_find_backing_image(bs, base); > if (base_bs == NULL) { > @@ -1894,6 +1898,10 @@ void qmp_block_commit(const char *device, > return; > } > > + if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_COMMIT, errp)) { > + return; > + } > + Is the blocker intended to operate at the device level, i.e. to mark a whole chain as 'blocked' for one or more operations? Or, is it intended to block at the singular BDS level (the commit message in patch 2 implies this meaning)? More to the point: if a BDS is marked as blocked, does that also imply all of the images in its backing chain are also considered blocked? Conversely, if a BDS is *not* marked as blocked, does that mean all of its backing chain is also unblocked? If the answer to the two questions above is 'yes', then the bdrv_op_block/unblock functions should probably operate recursively down the chain to the bottom-most backing file. If the answer is 'no', then for some operations like stream and commit (and probably others), don't we also need to worry about the blocker state of a lot more images in the chain? > /* default top_bs is the active layer */ > top_bs = bs; > > diff --git a/blockjob.c b/blockjob.c > index 60e72f5..7d84ca1 100644 > --- a/blockjob.c > +++ b/blockjob.c > @@ -41,7 +41,7 @@ void *block_job_create(const BlockJobDriver *driver, BlockDriverState *bs, > { > BlockJob *job; > > - if (bs->job || !bdrv_op_blocker_is_empty(bs)) { > + if (bs->job) { > error_set(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs)); > return NULL; > } > -- > 1.9.2 >