qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	qemu block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] loading bitmaps in invalidate_cache fails
Date: Tue, 12 Sep 2017 11:46:22 +0200	[thread overview]
Message-ID: <20170912094622.GC29136@localhost.localdomain> (raw)
In-Reply-To: <ce76e902-f048-1110-15cf-0dc7251322b2@virtuozzo.com>

Am 11.09.2017 um 18:51 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Hi Kevin!
> 
> I'm confused with relations of permissions and invalidation, can you please
> help?
> 
> Now dirty bitmaps are loaded in invalidate_cache. Here is a problem with
> migration:
> 
> 1. destination starts (inactive)
> 
> 2. load bitmaps readonly
> 
> ...
> 
> 3. invalidate_cache: here we should make our loaded bitmaps RW, ie set
> BdrvDirtyBitmap->readonly
> 
>   to false and set IN_USE bit in the image. But the latter goes into
> "bdrv_aligned_pwritev: Assertion `child->perm & BLK_PERM_WRITE' failed",
> 
>   because in bdrv_invalidate_cache we call bdrv_set_perm after
> drv->bdrv_invalidate_cache.
> 
> 
> What is the true way of fixing this?

It's all still a bit of a mess. :-(

I think it makes a lot of sense that we should activate the lower layers
first, so the order in bdrv_invalidate_cache() looks wrong. It should be
something like this:

1. invalidate_cache() for the children
2. Update permissions for non-BDRV_O_INACTIVE
3. Call drv->bdrv_invalidate_cache()

I'm currently working on some fixes related to bdrv_reopen() where
things become tricky because the updated permissions shouldn't depend on
the current state, but on the state after the operation has finished.

You get something similar here, but I think just making sure that we
clear BDRV_O_INACTIVE before updating the permissions is enough here.
The only thing to be careful is that in error cases, we need to revert
both the flag and the permissions then.

Kevin

  reply	other threads:[~2017-09-12  9:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-11 16:51 [Qemu-devel] loading bitmaps in invalidate_cache fails Vladimir Sementsov-Ogievskiy
2017-09-12  9:46 ` Kevin Wolf [this message]
2017-09-28 13:06   ` [Qemu-devel] [PATCH] iotests: test clearing unknown autoclear_features by qcow2 Vladimir Sementsov-Ogievskiy
2017-09-28 13:26     ` no-reply
2017-10-05  9:41   ` [Qemu-devel] loading bitmaps in invalidate_cache fails Vladimir Sementsov-Ogievskiy
2017-10-30 14:55     ` [Qemu-devel] ping " Vladimir Sementsov-Ogievskiy

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=20170912094622.GC29136@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.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).