From nobody Thu May 2 14:37:50 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=virtuozzo.com ARC-Seal: i=1; a=rsa-sha256; t=1564772531; cv=none; d=zoho.com; s=zohoarc; b=Mlx/3UaNY16GuWJp1aWFkuzklkNTs2SVuePUjkzsvPg5+FUHQ1mcYX2J5l/hAkKuPcBMCdPYQyJ7IdhyTDeWwT0OI1ZuELNS21sJqQxNhSnA0htycMJpFlELr/eB1Qzz1ZHWco4k7AYiVPLMi+YHB31Pgg6MSDwQA31whvZZ++k= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1564772531; h=Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=HQonensYlT3TB8tWAyc0OSi6pZ9CQdQ4CvhSh9uc8Cw=; b=LmgxkNdJ4z7qaQwAKdKPYeyOZuwKe185wpSiUXMy0h7Ls49JMXbzriMAb6GRN1SpA5eZ50QdQxVaomyjmJA41hSJamn2ZoSKq+PitaGvvty7w39PwN1h3g5ada3MsJyj7t0jG0BJnCb5jadnTF7N1lJWgIZ8zO/RwBpKItXV0R8= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1564772531688690.4431146994164; Fri, 2 Aug 2019 12:02:11 -0700 (PDT) Received: from localhost ([::1]:37034 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htcoV-00060D-R8 for importer@patchew.org; Fri, 02 Aug 2019 15:02:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41080) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htcli-0005MB-8u for qemu-devel@nongnu.org; Fri, 02 Aug 2019 14:59:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htclU-0002fo-Ty for qemu-devel@nongnu.org; Fri, 02 Aug 2019 14:59:00 -0400 Received: from relay.sw.ru ([185.231.240.75]:46130) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1htclA-0002UE-7t; Fri, 02 Aug 2019 14:58:37 -0400 Received: from [10.94.3.0] (helo=kvm.qa.sw.ru) by relay.sw.ru with esmtp (Exim 4.92) (envelope-from ) id 1htcl5-0003Cw-Hn; Fri, 02 Aug 2019 21:58:31 +0300 From: Vladimir Sementsov-Ogievskiy To: qemu-block@nongnu.org Date: Fri, 2 Aug 2019 21:58:30 +0300 Message-Id: <20190802185830.74648-1-vsementsov@virtuozzo.com> X-Mailer: git-send-email 2.18.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 185.231.240.75 Subject: [Qemu-devel] [PATCH] util/hbitmap: fix unaligned reset X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fam@euphon.net, kwolf@redhat.com, vsementsov@virtuozzo.com, qemu-devel@nongnu.org, mreitz@redhat.com, den@openvz.org, jsnow@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" hbitmap_reset is broken: it rounds up the requested region. It leads to the following bug, which is shown by fixed test: assume granularity =3D 2 set(0, 3) # count becomes 4 reset(0, 1) # count becomes 2 But user of the interface assume that virtual bit 1 should be still dirty, so hbitmap should report count to be 4! In other words, because of granularity, when we set one "virtual" bit, yes, we make all "virtual" bits in same chunk to be dirty. But this should not be so for reset. Fix this, aligning bound correctly. Signed-off-by: Vladimir Sementsov-Ogievskiy --- Hi all! Hmm, is it a bug or feature? :) I don't have a test for mirror yet, but I think that sync mirror may be bro= ken because of this, as do_sync_target_write() seems to be using unaligned rese= t. tests/test-hbitmap.c | 2 +- util/hbitmap.c | 24 +++++++++++++++++++----- 2 files changed, 20 insertions(+), 6 deletions(-) diff --git a/tests/test-hbitmap.c b/tests/test-hbitmap.c index 592d8219db..0008025a9f 100644 --- a/tests/test-hbitmap.c +++ b/tests/test-hbitmap.c @@ -424,7 +424,7 @@ static void test_hbitmap_granularity(TestHBitmapData *d= ata, hbitmap_test_set(data, 0, 3); g_assert_cmpint(hbitmap_count(data->hb), =3D=3D, 4); hbitmap_test_reset(data, 0, 1); - g_assert_cmpint(hbitmap_count(data->hb), =3D=3D, 2); + g_assert_cmpint(hbitmap_count(data->hb), =3D=3D, 4); } =20 static void test_hbitmap_iter_granularity(TestHBitmapData *data, diff --git a/util/hbitmap.c b/util/hbitmap.c index 7905212a8b..61a813994a 100644 --- a/util/hbitmap.c +++ b/util/hbitmap.c @@ -473,15 +473,29 @@ void hbitmap_reset(HBitmap *hb, uint64_t start, uint6= 4_t count) { /* Compute range in the last layer. */ uint64_t first; - uint64_t last =3D start + count - 1; + uint64_t last; + uint64_t end =3D start + count; + uint64_t gran =3D UINT64_C(1) << hb->granularity; =20 - trace_hbitmap_reset(hb, start, count, - start >> hb->granularity, last >> hb->granularity); + /* + * We should clear only bits, fully covered by requested region. Other= wise + * we may clear something that is actually still dirty. + */ + first =3D DIV_ROUND_UP(start, gran); =20 - first =3D start >> hb->granularity; - last >>=3D hb->granularity; + if (end =3D=3D hb->orig_size) { + end =3D DIV_ROUND_UP(end, gran); + } else { + end =3D end >> hb->granularity; + } + if (end <=3D first) { + return; + } + last =3D end - 1; assert(last < hb->size); =20 + trace_hbitmap_reset(hb, start, count, first, last); + hb->count -=3D hb_count_between(hb, first, last); if (hb_reset_between(hb, HBITMAP_LEVELS - 1, first, last) && hb->meta) { --=20 2.18.0