Message ID | Y6HDwOyR23QPssRa@qemulion |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp2992173wrn; Tue, 20 Dec 2022 06:22:52 -0800 (PST) X-Google-Smtp-Source: AMrXdXtznza7DEY8M0sDzfRKihhyBpyxvuyEUJSUOQioPV/mLwGThO5kgL9vl4KzxKXGGgPiSs3T X-Received: by 2002:a17:90a:9907:b0:223:3d3d:5149 with SMTP id b7-20020a17090a990700b002233d3d5149mr23255499pjp.13.1671546172071; Tue, 20 Dec 2022 06:22:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671546172; cv=none; d=google.com; s=arc-20160816; b=uqZjDCj3IiSdTPqiZcBXLVCg4BByPCNmS2B4yzAn7Z6lqvPhIobBO/H9mlLabf5ZHZ 9ILNIvs+JvDslyrccJXSL+2x0LjU+rXHZhyGzyjr+IYCf2Fk9RHQzByLhTxUUvU++Lti 7952gixSJrrYrNUxDOnTU0Sf03szicBz3gwu0Ofob0Ih8VfZ4LQDpKps3lZO035Rck1J v8ElLOKbQWPz/Ca7z4usQHHPeSqMG6yqHgOHGfo6htUdw+c5SsV+ioKO4Dm4Ppx6Ygy6 ZRMzrta9V5HTgj1j6Vqz/5weMoM3uJg+TCjh7w/dZ2PGhnAe4g5f3S5AUAQZO0z21UbM o3pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=eKcgKgylhiBefPL7sXm2EAu1DKL8/s4fi7N3xgfZl3U=; b=zpipa3faQ6+bOu21u1eUYvEOP28PQty1lHuZXxnUnhGXVJEgPibwx7yC4s1K81t7Z2 FA3LlzpXsiC+pt9HSj3FpK3YJIoZJtvUOoqUu3ShMeH4ZuqzKz9Q5dsULHROKjUyXlyQ 4mTyR41O1qHM9iCvC1pUfweJ0vYZJArZd7ahtfe/+zYysbFeMOOclwTFKkP2WzuROtWr Ne+ZClmsQ1GbO0C01atoL/Vmp5yZPFaO9C1K7bNXoj8J9V3JfUIhZsoYlJ/N4ATBn9PA KBLQtfPRe9dh3WeqPA+IOyZYeLBLzC6UZPPJhrTPoR3zDN3O5ACwAZrEOK10LFEZWuRn R5qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=Afvz7mrs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nd10-20020a17090b4cca00b00218f916f005si13850346pjb.121.2022.12.20.06.22.37; Tue, 20 Dec 2022 06:22:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@mailo.com header.s=mailo header.b=Afvz7mrs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mailo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233953AbiLTOSL (ORCPT <rfc822;abdi.embedded@gmail.com> + 99 others); Tue, 20 Dec 2022 09:18:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233948AbiLTORi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 20 Dec 2022 09:17:38 -0500 Received: from msg-2.mailo.com (msg-2.mailo.com [213.182.54.12]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 593D2E0F2 for <linux-kernel@vger.kernel.org>; Tue, 20 Dec 2022 06:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailo.com; s=mailo; t=1671545803; bh=KFy9i0U+bz5w8ZNQPETAfc303KW3oDGaFSwUS0I9Z7Y=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:MIME-Version: Content-Type; b=Afvz7mrsiDCgrGiDOYGru1q/4CJKU+h4mzfJJv9UqrwG4ed3Qi3AVAFKJIg4/7qee ClaTK7yGkMDRp5fmDVp9cUXfOH0XmGZ7NVxPyVzUi58fuBJ4xSS2110W6Uiq+KeT3p pQy4hAox9nBiqXnb+3sP6G2hYNF+lLAHQW4iEIfM= 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:16:43 +0100 (CET) X-EA-Auth: ht9cxGNE36MfwDJyGTplQ3KyBpF29jM0Yl/k5AFuB85lfHkYRBCHHBwHRBFEOuzVkAcq944OAyB/kI1/c0sM/TPaAgdnykvt Date: Tue, 20 Dec 2022 19:46:32 +0530 From: Deepak R Varma <drv@mailo.com> To: Russell King <linux@armlinux.org.uk>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Praveen Kumar <kumarpraveen@linux.microsoft.com>, Saurabh Singh Sengar <ssengar@microsoft.com>, Julia Lawall <julia.lawall@inria.fr>, drv@mailo.com Subject: [PATCH v2] ARM/dma-mapping: use kvcalloc for fallback memory allocation need Message-ID: <Y6HDwOyR23QPssRa@qemulion> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752743199000671614?= X-GMAIL-MSGID: =?utf-8?q?1752743199000671614?= |
Series |
[v2] ARM/dma-mapping: use kvcalloc for fallback memory allocation need
|
|
Commit Message
Deepak R Varma
Dec. 20, 2022, 2:16 p.m. UTC
Current conditional determination of whether to use kzalloc or vzalloc
has known issues such as "indefinite retry" when less than PAGE_SIZE
memory is needed, but is unavailable. This LWN article [1] describes
these issues in greater detail. Use helper function kvcalloc() instead
which is more efficient in terms of performance and security.
[1] https://lwn.net/Articles/711653/
This patch proposal is based on following Coccinelle warning using the
kvmalloc.cocci semantic patch.
arch/arm/mm/dma-mapping.c:858:28-29: WARNING opportunity for kvmalloc
The semantic patch suggests using kvzalloc() helper function, however,
this patch proposes to use kvcalloc instead. kvcalloc() helper function
uses 2-factor argument form which is better from a security perspective
as described in the following KSPP project commit.
Commit 4e3fd7217105 ("wireguard: ratelimiter: use kvcalloc() instead of kvzalloc()")
Signed-off-by: Deepak R Varma <drv@mailo.com>
---
Changes in v2:
1. Update patch subject to use kvcalloc
2. Use kvcalloc instead of kvzalloc helper function. Revise the patch
proposal and the patch description accordingly.
arch/arm/mm/dma-mapping.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--
2.34.1
Comments
On Tue, Dec 20, 2022 at 07:46:32PM +0530, Deepak R Varma wrote: > Current conditional determination of whether to use kzalloc or vzalloc > has known issues such as "indefinite retry" when less than PAGE_SIZE > memory is needed, but is unavailable. This LWN article [1] describes > these issues in greater detail. Use helper function kvcalloc() instead > which is more efficient in terms of performance and security. > > [1] https://lwn.net/Articles/711653/ > > This patch proposal is based on following Coccinelle warning using the > kvmalloc.cocci semantic patch. > arch/arm/mm/dma-mapping.c:858:28-29: WARNING opportunity for kvmalloc > > The semantic patch suggests using kvzalloc() helper function, however, > this patch proposes to use kvcalloc instead. kvcalloc() helper function > uses 2-factor argument form which is better from a security perspective > as described in the following KSPP project commit. > > Commit 4e3fd7217105 ("wireguard: ratelimiter: use kvcalloc() instead of kvzalloc()") > > Signed-off-by: Deepak R Varma <drv@mailo.com> Hello, May I please request a review and feedback on this patch proposal? Thank you, ./drv > --- > > Changes in v2: > 1. Update patch subject to use kvcalloc > 2. Use kvcalloc instead of kvzalloc helper function. Revise the patch > proposal and the patch description accordingly. > > > arch/arm/mm/dma-mapping.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > index c135f6e37a00..35092ecd30e1 100644 > --- a/arch/arm/mm/dma-mapping.c > +++ b/arch/arm/mm/dma-mapping.c > @@ -851,14 +851,10 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, > { > struct page **pages; > int count = size >> PAGE_SHIFT; > - int array_size = count * sizeof(struct page *); > int i = 0; > int order_idx = 0; > > - if (array_size <= PAGE_SIZE) > - pages = kzalloc(array_size, GFP_KERNEL); > - else > - pages = vzalloc(array_size); > + pages = kvcalloc(count, sizeof(struct page *), GFP_KERNEL); > if (!pages) > return NULL; > > -- > 2.34.1 >
On Wed, Dec 28, 2022 at 03:49:44PM +0530, Deepak R Varma wrote: > On Tue, Dec 20, 2022 at 07:46:32PM +0530, Deepak R Varma wrote: > > Current conditional determination of whether to use kzalloc or vzalloc > > has known issues such as "indefinite retry" when less than PAGE_SIZE > > memory is needed, but is unavailable. This LWN article [1] describes > > these issues in greater detail. Use helper function kvcalloc() instead > > which is more efficient in terms of performance and security. > > > > [1] https://lwn.net/Articles/711653/ > > > > This patch proposal is based on following Coccinelle warning using the > > kvmalloc.cocci semantic patch. > > arch/arm/mm/dma-mapping.c:858:28-29: WARNING opportunity for kvmalloc > > > > The semantic patch suggests using kvzalloc() helper function, however, > > this patch proposes to use kvcalloc instead. kvcalloc() helper function > > uses 2-factor argument form which is better from a security perspective > > as described in the following KSPP project commit. > > > > Commit 4e3fd7217105 ("wireguard: ratelimiter: use kvcalloc() instead of kvzalloc()") > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > Hello, > May I please request a review and feedback on this patch proposal? The DMA API on ARM has been maintained by others recently, so it's no longer up to me. Please include Christoph Hellwig <hch@lst.de> when sending changes for this. Thanks.
On Tue, Jan 03, 2023 at 10:19:20AM +0000, Russell King (Oracle) wrote: > On Wed, Dec 28, 2022 at 03:49:44PM +0530, Deepak R Varma wrote: > > On Tue, Dec 20, 2022 at 07:46:32PM +0530, Deepak R Varma wrote: > > > Current conditional determination of whether to use kzalloc or vzalloc > > > has known issues such as "indefinite retry" when less than PAGE_SIZE > > > memory is needed, but is unavailable. This LWN article [1] describes > > > these issues in greater detail. Use helper function kvcalloc() instead > > > which is more efficient in terms of performance and security. > > > > > > [1] https://lwn.net/Articles/711653/ > > > > > > This patch proposal is based on following Coccinelle warning using the > > > kvmalloc.cocci semantic patch. > > > arch/arm/mm/dma-mapping.c:858:28-29: WARNING opportunity for kvmalloc > > > > > > The semantic patch suggests using kvzalloc() helper function, however, > > > this patch proposes to use kvcalloc instead. kvcalloc() helper function > > > uses 2-factor argument form which is better from a security perspective > > > as described in the following KSPP project commit. > > > > > > Commit 4e3fd7217105 ("wireguard: ratelimiter: use kvcalloc() instead of kvzalloc()") > > > > > > Signed-off-by: Deepak R Varma <drv@mailo.com> > > > > Hello, > > May I please request a review and feedback on this patch proposal? > > The DMA API on ARM has been maintained by others recently, so it's no > longer up to me. Please include Christoph Hellwig <hch@lst.de> when > sending changes for this. Thanks. Sure. Actually the get_maintainer.pl scripts still returns yourself as the maintainer for this driver. Hence the email to you. I will send a v3 and include the change you asked for. I will keep you in cc if you don't mind. Also, let me know if I can help with getting the maintainer list updated for this core subsystem. Thank you, ./drv > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index c135f6e37a00..35092ecd30e1 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -851,14 +851,10 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, { struct page **pages; int count = size >> PAGE_SHIFT; - int array_size = count * sizeof(struct page *); int i = 0; int order_idx = 0; - if (array_size <= PAGE_SIZE) - pages = kzalloc(array_size, GFP_KERNEL); - else - pages = vzalloc(array_size); + pages = kvcalloc(count, sizeof(struct page *), GFP_KERNEL); if (!pages) return NULL;