From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2avR-0004F7-W0 for qemu-devel@nongnu.org; Wed, 10 Jun 2015 03:59:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2avQ-0002uz-QL for qemu-devel@nongnu.org; Wed, 10 Jun 2015 03:59:53 -0400 Date: Wed, 10 Jun 2015 09:59:41 +0200 From: Kevin Wolf Message-ID: <20150610075941.GC4899@noname.str.redhat.com> References: <1433796555-5608-1-git-send-email-jsnow@redhat.com> <20150609092403.GB4329@noname.str.redhat.com> <55770A49.3040206@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55770A49.3040206@redhat.com> Subject: Re: [Qemu-devel] [PATCH] block: record new size in bdrv_dirty_bitmap_truncate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: qemu-block@nongnu.org, vsementsov@virtuozzo.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 09.06.2015 um 17:46 hat John Snow geschrieben: > > > On 06/09/2015 05:24 AM, Kevin Wolf wrote: > > Am 08.06.2015 um 22:49 hat John Snow geschrieben: > >> ce1ffea8 neglected to update the BdrvDirtyBitmap structure > >> itself for internal consistency. It's currently not an issue, > >> but for migration and persistence series this will cause headaches. > >> > >> Signed-off-by: John Snow > > > > I know nothing about dirty bitmaps, but this one looks obvious enough, > > I'll apply it. > > > >> diff --git a/block.c b/block.c > >> index 2b9ceae..2786e47 100644 > >> --- a/block.c > >> +++ b/block.c > >> @@ -3224,6 +3224,7 @@ static void bdrv_dirty_bitmap_truncate(BlockDriverState *bs) > >> continue; > >> } > >> hbitmap_truncate(bitmap->bitmap, size); > >> + bitmap->size = size; > >> } > >> } > > > > However, I'm left wondering whether that 'continue' in the context of > > that hunk is right. More context: > > > > QLIST_FOREACH(bitmap, &bs->dirty_bitmaps, list) { > > if (bdrv_dirty_bitmap_frozen(bitmap)) { > > continue; > > } > > hbitmap_truncate(bitmap->bitmap, size); > > } > > > > If the image just shrunk, the frozen bitmap covers parts of the image > > that don't exist any more. When they are read out for the backup, that > > request would fail. > > > > If the image was extended, the frozen bitmap covers only part of the > > image. There are a few bitmap functions that don't check the size and > > would just work beyond the end of the bitmap if called with a now valid > > sector number that is outside the image. > > > > In practice, I don't think any of these happen because of op blockers > > that prevent resizing while a backup is in progress, but should > > !bdrv_dirty_bitmap_frozen(bitmap) be asserted then rather than just > > skipping the bitmap? > > > > Kevin > > > > Yeah, that won't hurt anything and will read cleaner. I'll just v2 this > patch, thanks. It's unrelated to this patch (except for touching the same function), so I'd suggest to make it a separate patch. Kevin