Received: by 2002:a9a:4c47:0:b029:116:c383:538 with SMTP id u7csp991524lko; Tue, 13 Jul 2021 14:38:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyq5puXtcHk5cnPc3hvZ3cG8m6+yKXgSAIgTtZ+VPEuKphhy4Cq/Xrz4YAmF5rZCD98EM72 X-Received: by 2002:a17:906:4dcf:: with SMTP id f15mr8136762ejw.400.1626212283945; Tue, 13 Jul 2021 14:38:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626212283; cv=none; d=google.com; s=arc-20160816; b=Lb92wFLjqJjOdPd7URrZOZ/KgeX9tpmXUqC3ZcYlXPKs+GAI/fPnxEEClKOmXzI8CM FTtAAnrUjH2CWcwmLLzGoUUXCr2+BZzRrUBJAej8g2veDIERkPxt433DCDwKeMNIBDMU Qn1gwJeHWjoMMQO6/iGZSLcRx7MAIBGKYQV3uYYfDz0bDbpfo2WQ9atWDkoNGJEzpoXG 4XBKQjluIB9fGXvdHCl+Vc3fTz85JYHsWLrbX3TjCUEPWO42XU/K5loLq9Cue/BOR5Fx 6MQToc+k8nIT6c/EWLmpovo6v7K2KUuHc46eqP+BYoliK4dbnGqduo7vAkBXriX1/TBe FYFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:ironport-hdrordr; bh=PkyMo8ti9qE/AKYkXxy8Z31QgUXkXwhNJPaIeWoVkSE=; b=YxPML4hjVjufLPC5Tewe1mSbS+ybT+iUbS2Rl9sXnpUjGhIQtLBAEXVI10ohmDcJLl 1Em+Gp/a0iwvWdBjTIeNKfE8eoL6hYWmflesp3UgYR3V4nImyOh99bplIMV/2Q+eu3EP 4aN0/LTLq8x2iiM8Gzo0UQ9Fs86wemdc5nu8YxjcETNw0DbY6bXjtMpygPETRVBRjKKV +s/ZhGH/eZbExs/yiNq2Q9HrnaCUBgwf6TBRf1+sQVWed7DLWWoWjUAliWkA50b2EAWz PqS8QuZW+RO5eEi5IlutsPbkEwFe5wZhPn1Hr+O7J6BtBP3lT1/9zlKjKxgB8zmLPn5D 1Q/Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r16si21319eda.37.2021.07.13.14.37.38; Tue, 13 Jul 2021 14:38:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235708AbhGMVgH (ORCPT + 99 others); Tue, 13 Jul 2021 17:36:07 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:4727 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229478AbhGMVgH (ORCPT ); Tue, 13 Jul 2021 17:36:07 -0400 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AywMQU6h2J3nGR6e/vqyf7z2903BQXr8ji2hC?= =?us-ascii?q?6mlwRA09TyX4rbHMoB1/73TJYVkqN03I9ervBEDiexPhHPxOgLX5VI3KNGPbUQ?= =?us-ascii?q?CTQL2Kg7GO/wHd?= X-IronPort-AV: E=Sophos;i="5.84,237,1620684000"; d="scan'208";a="387979542" Received: from 173.121.68.85.rev.sfr.net (HELO hadrien) ([85.68.121.173]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2021 23:33:15 +0200 Date: Tue, 13 Jul 2021 23:33:15 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Joe Perches cc: cocci , LKML , kernel-janitors@vger.kernel.org Subject: Re: cocci script to convert linux-kernel allocs with BITS_TO_LONGS to bitmap_alloc In-Reply-To: Message-ID: References: <08b89608cfb1280624d1a89ead6547069f9a4c31.camel@perches.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 10 Jul 2021, Joe Perches wrote: > On Sat, 2021-07-10 at 21:50 +0200, Julia Lawall wrote: > > On Fri, 9 Jul 2021, Joe Perches wrote: > > > > > Here is a cocci script to convert various types of bitmap allocations > > > that use BITS_TO_LONGS to the more typical bitmap_alloc functions. I see that there is also a bitmap_free. Maybe the rule should be introducing that as well? julia > > > > > > Perhaps something like it could be added to scripts/coccinelle. > > > The diff produced by the script is also below. > > > > > > $ cat bitmap_allocs.cocci > > > // typical uses of bitmap allocations > [] > > > @@ > > > expression val; > > > expression e1; > > > expression e2; > > > @@ > > > > > > - val = kcalloc(BITS_TO_LONGS(e1), sizeof(*val), e2) > > > + val = bitmap_zalloc(e1, e2) > > > > Is there something that guarantees that val has a type that has a size that > > is the same as a long? > > no, but afaict, all do. > > >