From: Fam Zheng <famz@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: kwolf@redhat.com, hbrock@redhat.com, qemu-devel@nongnu.org,
rjones@redhat.com, imain@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 01/11] block: replace in_use with refcnt_soft and refcnt_hard
Date: Tue, 23 Jul 2013 18:32:25 +0800 [thread overview]
Message-ID: <20130723103225.GA7183@T430s.redhat.com> (raw)
In-Reply-To: <20130723093600.GB20256@stefanha-thinkpad.redhat.com>
On Tue, 07/23 11:36, Stefan Hajnoczi wrote:
> On Wed, Jul 17, 2013 at 05:42:06PM +0800, Fam Zheng wrote:
> > Introduce refcnt_soft (soft reference) and refcnt_hard (hard reference)
> > to BlockDriverState, since in_use mechanism cannot provide proper
> > management of lifecycle when a BDS is referenced in multiple places
> > (e.g. pointed to by another bs's backing_hd while also used as a block
> > job device, in the use case of image fleecing).
> >
> > The original in_use case is considered a "hard reference" in this patch,
> > where the bs is busy and should not be used in other tasks that require
> > a hard reference. (However the interface doesn't force this, caller
> > still need to call bdrv_in_use() to check by itself.).
> >
> > A soft reference is implemented but not used yet. It will be used in
> > following patches to manage the lifecycle together with hard reference.
> >
> > If bdrv_ref() is called on a BDS, it must be released by exactly the
> > same numbers of bdrv_unref() with the same "soft/hard" type, and never
> > call bdrv_delete() directly. If the BDS is only used locally (unnamed),
> > bdrv_ref/bdrv_unref can be skipped and just use bdrv_delete().
>
> It is risky to keep bdrv_delete() public. I suggest replacing
> bdrv_delete() callers with bdrv_unref() and then making bdrv_delete()
> static in block.c.
>
> This way it is impossible to make the mistake of calling bdrv_delete()
> on a BDS which has refcnt > 1.
>
> I don't really understand this patch. There are now two separate
> refcounts. They must both reach 0 for deletion to occur. I think
> you plan to treat the "hard" refcount like the in_use counter (there
> should only be 0 or 1 refs) but you don't enforce it. It seems cleaner
> to keep in_use separate: let in_use callers take a refcount and also set
> in_use.
OK, I like your ideas, make bdrv_delete private is much cleaner. Will
fix in next revision.
I plan to make it like this:
/* soft ref */
void bdrv_{ref,unref}(bs)
/* hard ref */
bool bdrv_hard_{ref,unref}(bs)
usage:
bs = bdrv_new()
<implicit bdrv_ref(bs) called>
...
bdrv_unref(bs)
<automatically deleted here>
or with hard ref:
bs = bdrv_new()
<implicit bdrv_ref() called>
bdrv_hard_ref(bs)
...
bdrv_hard_unref(bs)
bdrv_unref(bs)
<automatically deleted here>
The second bdrv_hard_ref call to a bs returns false, caller check the
return value.
--
Fam
next prev parent reply other threads:[~2013-07-23 10:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 9:42 [Qemu-devel] [PATCH v2 00/11] Point-in-time snapshot exporting over NBD Fam Zheng
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 01/11] block: replace in_use with refcnt_soft and refcnt_hard Fam Zheng
2013-07-17 12:26 ` Paolo Bonzini
2013-07-18 4:53 ` Fam Zheng
2013-07-23 9:36 ` Stefan Hajnoczi
2013-07-23 10:32 ` Fam Zheng [this message]
2013-07-23 13:34 ` Stefan Hajnoczi
2013-07-24 0:39 ` Fam Zheng
2013-07-24 7:35 ` Stefan Hajnoczi
2013-07-24 7:44 ` Fam Zheng
2013-07-25 7:52 ` Stefan Hajnoczi
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 02/11] block: use refcnt for bs->backing_hd and bs->file Fam Zheng
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 03/11] block: use refcnt for drive_init/drive_uninit Fam Zheng
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 04/11] block: use refcnt for device attach/detach Fam Zheng
2013-07-23 9:44 ` Stefan Hajnoczi
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 05/11] migration: omit drive ref as we have bdrv_ref now Fam Zheng
2013-07-23 9:49 ` Stefan Hajnoczi
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 06/11] xen_disk: simplify blk_disconnect with refcnt Fam Zheng
2013-07-23 9:50 ` Stefan Hajnoczi
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 07/11] block: hold hard reference for backup/mirror target Fam Zheng
2013-07-23 9:52 ` Stefan Hajnoczi
2013-07-25 6:08 ` Fam Zheng
2013-07-25 7:59 ` Stefan Hajnoczi
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 08/11] block: simplify bdrv_drop_intermediate Fam Zheng
2013-07-24 23:16 ` Jeff Cody
2013-07-25 1:34 ` Fam Zheng
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 09/11] block: add assertion to check refcount before deleting Fam Zheng
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 10/11] block: add option 'backing' to -drive options Fam Zheng
2013-07-17 12:36 ` Paolo Bonzini
2013-07-17 12:58 ` Kevin Wolf
2013-07-17 13:13 ` Paolo Bonzini
2013-07-17 13:48 ` Kevin Wolf
2013-07-17 14:16 ` Paolo Bonzini
2013-07-17 15:09 ` Kevin Wolf
2013-07-17 15:23 ` Paolo Bonzini
2013-07-23 20:07 ` Ian Main
2013-07-22 6:07 ` Fam Zheng
2013-07-23 19:57 ` Ian Main
2013-07-17 9:42 ` [Qemu-devel] [PATCH v2 11/11] qmp: add command 'blockdev-backup' Fam Zheng
2013-07-17 12:44 ` Eric Blake
2013-07-18 4:41 ` Fam Zheng
2013-07-19 10:16 ` Wenchao Xia
2013-07-23 10:10 ` Stefan Hajnoczi
2013-07-19 10:41 ` [Qemu-devel] [PATCH v2 00/11] Point-in-time snapshot exporting over NBD Wenchao Xia
2013-07-23 1:52 ` Wenchao Xia
2013-07-23 6:35 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130723103225.GA7183@T430s.redhat.com \
--to=famz@redhat.com \
--cc=hbrock@redhat.com \
--cc=imain@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).