From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 213DEC10F1E for ; Tue, 20 Dec 2022 14:27:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=a0NJinyHTia0GdnN1HaOt1dLcZb4Upw0znCKfRAUedQ=; b=gwgpsmfzjlT7NC txl4cEsSiEVpJZdZbgaClxnjw2H+5vSim4Vk4r6Qsb7hkbV3bTXTqKEwYls5xsn7eZEsnQpTFigq3 /Q6s394KvT91O5IysEGsdE/0o0DUxhHEEVVMzYO+qr7UdLAIyGOFoUkGwTNCCNJ19S+Gw3liuNEU2 gAX9Lx6mWfu0Qy8Y5aoE6lOrDgxwA2dVjbNf3B5/UZ5lSVh+F/QRbLy3aulRgSmEW/2MJ9FOP0acQ fkJtsgjukewF9J3dwrBs0RYXCbQlFBhpJIu9hn5pL+vYorkOSTzYCbJdvBMNH9nwAIt1zeZ4EmXOC eoeR6J1ckqur4fP1tYUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p7dZg-00GeoX-4r; Tue, 20 Dec 2022 14:26:32 +0000 Received: from msg-2.mailo.com ([213.182.54.12]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p7dZG-00GeW9-W2 for linux-arm-kernel@lists.infradead.org; Tue, 20 Dec 2022 14:26:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1671546341; bh=ocdMdN7aEukCgNOvKCL1W/7c1n4xooH9oWX7X7O+9ak=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To; b=l1PgyQg/4arUTt0mAgJ10WbsIiwWHvd0ZrJHsbXkcIB0xKLObamq1xsuAGDc75zbP lIZXuTZfP/mfc7rC6G13Kc4g9Flw11LORFK6l9+oj6l6MYkxMcB8tNXqaUti1lfLT9 ndCZVUIew/ZK4W7KyopKYQRP5et/oIvjvCSeIwKE= Received: by b-5.in.mailobj.net [192.168.90.15] with ESMTP via ip-206.mailobj.net [213.182.55.206] Tue, 20 Dec 2022 15:25:41 +0100 (CET) X-EA-Auth: LE+8xCnx1iNwbhLYvZp7EU7RNbGwdu2L+4eniJiGWquz5sL9G98+IX8GwLepM7zVR20NCngc7VtGoFwZFxWZjewJfBbtndOl Date: Tue, 20 Dec 2022 19:55:36 +0530 From: Deepak R Varma To: "Gustavo A. R. Silva" Cc: Julia Lawall , "Gustavo A. R. Silva" , Saurabh Singh Sengar , Praveen Kumar , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: kvzalloc vs kvcalloc Message-ID: References: <26b8353-dd33-1a57-d7b5-dc6a8583219@inria.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221220_062607_287018_83A86840 X-CRM114-Status: GOOD ( 30.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Dec 20, 2022 at 08:13:19AM -0600, Gustavo A. R. Silva wrote: > > > On 12/20/22 01:48, Julia Lawall wrote: > > > > > > On Tue, 20 Dec 2022, Deepak R Varma wrote: > > > > > On Tue, Dec 20, 2022 at 08:39:09AM +0100, Julia Lawall wrote: > > > > > > > > > > > > On Tue, 20 Dec 2022, Deepak R Varma wrote: > > > > > > > > > On Tue, Dec 20, 2022 at 07:08:24AM +0100, Julia Lawall wrote: > > > > > > > > > > > > > > > > > > On Tue, 20 Dec 2022, Deepak R Varma wrote: > > > > > > > > > > > > > Hello Gustavo and Julia, > > > > > > > I was working on building a patch proposal using the kvmalloc.cocci file for a > > > > > > > driver. The recommendation from the semantic patch is to use kvzalloc instead of > > > > > > > a fallback memory allocation model. Please see my patch submitted here [1]. > > > > > > > > > > > > > > I also found another patch submitted by Gustavo [2] which suggests using > > > > > > > kvcalloc instead of kvzalloc. Unfortunately, I was not able to understand the > > > > > > > reasons/advantages using kvcalloc over kvzalloc. > > Look for the definitions of those functions and try to understand their differences. > In many cases you have go down the rabbit hole, but you should be able to get a good > grasp of the thing in question before hitting the bottom. :) > > Look for a couple of instances in the codebase where those functions are being used > and try to understand a bit of the context around them. In some cases reading the > commit logs is necessary. Hello Gustavo, Thank you very much for the suggestion here. I will get deeper into the codebase and try to self learn. Your advise on reading the past commit logs is useful as well. Thank you again! ./drv > > > > > > > > > > > > > The calloc variants are for zeroed arrays. zalloc variants just zero. > > > > > > > > > > Thank you Julia and sorry to have missed the references in my email: > > > > > > > > In Gustavo's case, the array has a certain number of elements of a certain > > > > size. I don't know if you have both pieces of information in your case. > > > > calloc functions take them in separately, and do the multiplication in a > > > > way that checks for overflows. > > > > > > That is correct and I do have both the pieces, the size and number. This > > > actually further optimizes the code. We can eliminate the array_size variable > > > with the kvcalloc implementation. It is not used beyond the memory allocation. > > > > > > Please this code snip: > > > > > > 853 int count = size >> PAGE_SHIFT; > > > 1 int array_size = count * sizeof(struct page *); > > > 2 int i = 0; > > > 3 int order_idx = 0; > > > 4 > > > 5 pages = kvzalloc(array_size, GFP_KERNEL); > > > 6 if (!pages) > > > 7 return NULL; > > > > > > Thank you for your advise. I will wait to see Gustavo has any further guidance. > > > I will send in a revision to my patch accordingly. > > > > Great. A calloc function definitely looks like a good choice here. > > As Julia suggested, and as you may had realized already, the calloc function is the > way to go, in this case. > > -- > Gustavo > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel