All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: Jeff Cody <jcody@redhat.com>
Cc: kwolf@redhat.com, benoit.canet@irqsave.net, rjones@redhat.com,
	qemu-devel@nongnu.org, armbru@redhat.com, imain@redhat.com,
	stefanha@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v14 08/14] block: Support dropping active in bdrv_drop_intermediate
Date: Thu, 20 Feb 2014 16:34:15 +0800	[thread overview]
Message-ID: <20140220083415.GE6744@T430.redhat.com> (raw)
In-Reply-To: <20140220055731.GB30664@localhost.localdomain>

On Thu, 02/20 00:57, Jeff Cody wrote:
> On Thu, Feb 20, 2014 at 12:37:17PM +0800, Fam Zheng wrote:
> > On Wed, 02/19 18:24, Jeff Cody wrote:
> > > On Wed, Feb 19, 2014 at 04:22:30PM -0500, Jeff Cody wrote:
> > > > On Wed, Feb 19, 2014 at 09:42:25PM +0800, Fam Zheng wrote:
> > > > >  /*
> > > > > - * Drops images above 'base' up to and including 'top', and sets the image
> > > > > - * above 'top' to have base as its backing file.
> > > > > + * Drops images above 'base' up to and including 'top', and sets new 'base'
> > > > > + * as backing_hd of top_overlay (the image orignally has 'top' as backing
> > > > 
> > > > What is 'top_overlay'?  Do you mean "top's overlay" by this?
> > 
> > Yes, as noted in the parenthesis.
> >
> 
> I would just say "top's overlay".  What I found confusing by that, is
> when you reference something like 'top_overlay', it looks like an
> actual variable name.  So I was searching for that variable name, and
> wondered if it was just vestigial from an earlier revision.  Maybe
> that is just me, though :)
> 

I will update the wording for less confusion. Sorry about that.

> > > > And in the non-active case here, everything between top->backing_hd
> > > > and the original base is orphaned as well.  These should all be
> > > > explicitly unreferenced.
> > > 
> > > Same here, bdrv_unref() will eventually go through the chain, starting
> > > from top->backing_hd.  But this is a problem; won't we end up in a
> > > loop then?
> > 
> > Although the content is swapped, the pointer is not:
> > 
> > (I presume your "[base]" and "[top]" are denoting content, not pointer)
> >
> 
> Correct.  But part of the content that is swapped, are the backing_hd
> pointers.
> 
> > > 
> > > Take this chain:
> > > 
> > > drop_start = [A]
> > > 
> > >     |||-- ([base]) <-- [B] <--- [A] <--- ([top]) <--- [active]
> >                ^                              ^
> >                |                              |
> >               base                           top
> > > 
> > > 
> > > bdrv_swap(top, base):
> > > 
> > >     -- [B] <-- [A] <-- ([top])    |||--- ([base]) <-- [active]
> >                             ^                 ^
> >                             |                 |
> >                            base               top
> > >     |                    ^
> > >     |                    |
> > >     ---------------------
> > > 
> 
> Correct, those are the pointers.
> 
> > > Then we call bdrv_unref(drop_start (or bdrv_set_backing_hd() does),
> > > and we end up with:
> > > 
> 
> dropping an anchor here: [1]
> 
> > > bdrv_unref(A)
> > >     bdrv_unref(B)
> > >         bdrv_unref(top)
> > >             bdrv_unref(A) <--- assert
> > >                 .....
> > >             
> > > 
> > > So I think we want this line:
> > > 
> > > > > +            bdrv_set_backing_hd(base, NULL);
> > 
> > so, this breaks the chain,
> 
> Yes, you are right, we want base->backing_hd to be NULL.  But the
> chain has not been broken yet.
> 
> The loop [1] still exists, because once we enter bdrv_set_backing_hd()
> we begin to call bdrv_unref(A). And base_ptr->backing_hd still points
> to A, and B will point to base_ptr.

Yes, that need to be fixed.

> 
> Here is the first part of bdrv_set_backing_hd():
>     if (bs->backing_hd) {
>         bdrv_op_unblock_all(bs->backing_hd, bs->backing_blocker);
>         bdrv_unref(bs->backing_hd);
> 
> 
> > 
> > > 
> > > To be:
> > > 
> > > > > +            bdrv_set_backing_hd(top, NULL);
> > 
> > This will lose track of original base's backing_hd.
> 
> Right, we don't want that, sorry...  I shouldn't have written that, my
> brain failed me.  I mentally conflated top and [top].
> 
> > 
> > So I think we are OK here.
> >
> 
> I don't think we are, we still need to address the backing_hd loop,
> and I think it needs to be done here, where we have the information.

Again, you are right :)

Thanks,
Fam

  reply	other threads:[~2014-02-20  8:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-19 13:42 [Qemu-devel] [PATCH v14 00/14] Drop in_use from BlockDriverState and enable point-in-time snapshot exporting over NBD Fam Zheng
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 01/14] block: Add BlockOpType enum Fam Zheng
2014-02-19 15:25   ` Benoît Canet
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 02/14] block: Introduce op_blockers to BlockDriverState Fam Zheng
2014-02-19 15:26   ` Benoît Canet
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 03/14] block: Replace in_use with operation blocker Fam Zheng
2014-02-19 15:26   ` Benoît Canet
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 04/14] block: Move op_blocker check from block_job_create to its caller Fam Zheng
2014-02-19 15:28   ` Benoît Canet
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 05/14] block: Add bdrv_set_backing_hd() Fam Zheng
2014-02-19 15:27   ` Benoît Canet
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 06/14] block: Add backing_blocker in BlockDriverState Fam Zheng
2014-02-19 15:32   ` Benoît Canet
2014-02-19 21:17   ` Jeff Cody
2014-02-20  5:01     ` Fam Zheng
2014-02-20  5:08       ` Jeff Cody
2014-02-20  8:28         ` Fam Zheng
2014-02-20 11:59           ` Jeff Cody
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 07/14] block: Parse "backing" option to reference existing BDS Fam Zheng
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 08/14] block: Support dropping active in bdrv_drop_intermediate Fam Zheng
2014-02-19 15:34   ` Benoît Canet
2014-02-19 21:22   ` Jeff Cody
2014-02-19 23:24     ` Jeff Cody
2014-02-20  4:37       ` Fam Zheng
2014-02-20  5:57         ` Jeff Cody
2014-02-20  8:34           ` Fam Zheng [this message]
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 09/14] stream: Use bdrv_drop_intermediate and drop close_unused_images Fam Zheng
2014-02-19 21:23   ` Jeff Cody
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 10/14] qmp: Add command 'blockdev-backup' Fam Zheng
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 11/14] block: Allow backup on referenced named BlockDriverState Fam Zheng
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 12/14] block: Add blockdev-backup to transaction Fam Zheng
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 13/14] qemu-iotests: Test blockdev-backup in 055 Fam Zheng
2014-02-19 13:42 ` [Qemu-devel] [PATCH v14 14/14] qemu-iotests: Image fleecing test case 081 Fam Zheng

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=20140220083415.GE6744@T430.redhat.com \
    --to=famz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=benoit.canet@irqsave.net \
    --cc=imain@redhat.com \
    --cc=jcody@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.