From patchwork Tue Nov 15 22:47:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Max Reitz X-Patchwork-Id: 9430627 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 196946047D for ; Tue, 15 Nov 2016 22:48:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EE40C28CD4 for ; Tue, 15 Nov 2016 22:48:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D026D28CE4; Tue, 15 Nov 2016 22:48:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7378128CD4 for ; Tue, 15 Nov 2016 22:48:10 +0000 (UTC) Received: from localhost ([::1]:49432 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6mWP-0005Pm-Jj for patchwork-qemu-devel@patchwork.kernel.org; Tue, 15 Nov 2016 17:48:09 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6mVy-0005Nd-PQ for qemu-devel@nongnu.org; Tue, 15 Nov 2016 17:47:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6mVx-0005u5-UA for qemu-devel@nongnu.org; Tue, 15 Nov 2016 17:47:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47058) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6mVt-0005t1-HA; Tue, 15 Nov 2016 17:47:37 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22CD2C05AA55; Tue, 15 Nov 2016 22:47:36 +0000 (UTC) Received: from localhost (ovpn-116-190.phx2.redhat.com [10.3.116.190]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFMlYDB001753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 17:47:35 -0500 From: Max Reitz To: qemu-block@nongnu.org Date: Tue, 15 Nov 2016 23:47:32 +0100 Message-Id: <20161115224732.1334-1-mreitz@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 15 Nov 2016 22:47:36 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH for-2.8 v2] hbitmap: Fix shifts of constants by granularity X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: John Snow , Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP An hbitmap's granularity may be anything from 0 to 63, so when shifting constants by its value, they should not be plain ints. Even having changed the types, hbitmap_serialization_granularity() still tries to shift 64 to the right by the granularity. This operation is undefined if the granularity is greater than 57. Adding an assertion is fine for now, because serializing is done only in tests so far, but this means that only bitmaps with a granularity below 58 can be serialized and we should thus add a hbitmap_is_serializable() function later. One of the two places touched in this patch uses QEMU_ALIGN_UP(x, 1 << y). We can use ROUND_UP() there, since the second parameter is obviously a power of two. Signed-off-by: Max Reitz Reviewed-by: Stefan Hajnoczi --- v2: - Fix the same issue in hbitmap_truncate() [Stefan] - Use ROUND_UP() instead of QEMU_ALIGN_UP() there (because we can) - Add an assertion to hbitmap_serialization_granularity() guaranteeing that the shift doesn't overflow; we can guarantee this so far because the only place where serialization functions are used in is the hbitmap test (I'll send a follow-up patch to allow users to check whether a certain bitmap can be (de-)serialized) --- util/hbitmap.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/util/hbitmap.c b/util/hbitmap.c index 5d1a21c..9f691b7 100644 --- a/util/hbitmap.c +++ b/util/hbitmap.c @@ -399,9 +399,13 @@ bool hbitmap_get(const HBitmap *hb, uint64_t item) uint64_t hbitmap_serialization_granularity(const HBitmap *hb) { + /* Must hold true so that the shift below is defined + * (ld(64) == 6, i.e. 1 << 6 == 64) */ + assert(hb->granularity < 64 - 6); + /* Require at least 64 bit granularity to be safe on both 64 bit and 32 bit * hosts. */ - return 64 << hb->granularity; + return UINT64_C(64) << hb->granularity; } /* Start should be aligned to serialization granularity, chunk size should be @@ -594,7 +598,7 @@ void hbitmap_truncate(HBitmap *hb, uint64_t size) if (shrink) { /* Don't clear partial granularity groups; * start at the first full one. */ - uint64_t start = QEMU_ALIGN_UP(num_elements, 1 << hb->granularity); + uint64_t start = ROUND_UP(num_elements, UINT64_C(1) << hb->granularity); uint64_t fix_count = (hb->size << hb->granularity) - start; assert(fix_count);