Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp526562imm; Fri, 12 Oct 2018 02:16:51 -0700 (PDT) X-Google-Smtp-Source: ACcGV61ttgscvtHnGO+4rFbL0h+FQpFZFEBc7oq71b8QxyUlhpe37pOgu58wcqVwFZfacOXBp3h7 X-Received: by 2002:a62:5d0c:: with SMTP id r12-v6mr5301784pfb.123.1539335811925; Fri, 12 Oct 2018 02:16:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539335811; cv=none; d=google.com; s=arc-20160816; b=fSKvJw67EerXMFBBvNlVl+0E+VQ/tSwUyMCJRa2eAnmJiWFMlCCuOindRcZ70anKgo v/oNKO0sFaY9ayoLyr+UDqC/u0VDibC2NbXfmGovHBrqgRiu7UBr7DiRbYe/RwuInEfV 0iFo9B5GCoZItgZJGLU5so8cxSYsR69yumV5auUJUflcirRM9+LrTQ9YcTzhxJrt3whn rCBpu7aYbbtz6hyASLIBg/vgTGvsvef4TNnu5z2+2ZVoiyh0w+5DN/AF1m15rJjsQz4Q GHB6NfBiI7aMKNECuLHGQLsj/JdDdNAIUSaYvjYS9YaLDZvke1pkFmOq9Hi7ST8ph6Ob L5Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=KBp4XKmHUSKOHSWzTPd+yHt5L4B8WTBr5rXZKDk3fJg=; b=bYX+fFdr4YCzFK+oEHZSNN/mojeLYbz1OwSDY5mHQ+cUhxN5uSaqgTFor6Lq3ggvjg 9q2U88DhVhoCOtqS2syb4pysVturMc6p6vJ1xu+7k1AZlNefgi9pBYjHgkWq5YaPTLQ5 OjJWrtqmBvRa+4fzBwyW4UirWuLuyqoDShE7E9/Q2qaXrBHv0J1Zd+CNqZl0luDE1nG5 kkzDrVn0dtfVLHcwRVDKfo+LRFV41UUFyn9QuPle6365NnvlyCaFrj97ihYUjJsdZWvq eu+E+yS3dKMk4/d+r5TxUeS+lVHSLx4xoxelYSFwK3cHN39GgjwBRsF6swH5sCb35Qfm DR0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n10-v6si666242pgr.291.2018.10.12.02.16.36; Fri, 12 Oct 2018 02:16:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728045AbeJLQro (ORCPT + 99 others); Fri, 12 Oct 2018 12:47:44 -0400 Received: from mail.bootlin.com ([62.4.15.54]:44378 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727808AbeJLQrn (ORCPT ); Fri, 12 Oct 2018 12:47:43 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id A31A72083D; Fri, 12 Oct 2018 11:16:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (AAubervilliers-681-1-7-245.w90-88.abo.wanadoo.fr [90.88.129.245]) by mail.bootlin.com (Postfix) with ESMTPSA id 5EBCF20703; Fri, 12 Oct 2018 11:16:02 +0200 (CEST) Date: Fri, 12 Oct 2018 11:16:03 +0200 From: Boris Brezillon To: Arnd Bergmann Cc: David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: sa1100: avoid VLA in sa1100_setup_mtd Message-ID: <20181012111603.0d03e043@bbrezillon> In-Reply-To: <20181010184533.691620-1-arnd@arndb.de> References: <20181010184533.691620-1-arnd@arndb.de> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On Wed, 10 Oct 2018 20:44:50 +0200 Arnd Bergmann wrote: > Enabling -Wvla found another variable-length array with randconfig > testing: > > drivers/mtd/maps/sa1100-flash.c: In function 'sa1100_setup_mtd': > drivers/mtd/maps/sa1100-flash.c:224:10: error: ISO C90 forbids variable length array 'cdev' [-Werror=vla] > > As far as I can tell, there is an upper bound on the number of resources > that can be passed, based on the number of CS lines on the bus. > In practice, all boards we support have either one or two resources, > but using six to be on the safe side has no extra cost. Why not dynamically allocate cdev instead? That removes any kind of guessing on the max value, and it shouldn't hurt much since this code is in the probe path. --->8--- diff --git a/drivers/mtd/maps/sa1100-flash.c b/drivers/mtd/maps/sa1100-flash.c index 784c6e1a0391..fd5fe12d7461 100644 --- a/drivers/mtd/maps/sa1100-flash.c +++ b/drivers/mtd/maps/sa1100-flash.c @@ -221,7 +221,14 @@ static struct sa_info *sa1100_setup_mtd(struct platform_device *pdev, info->mtd = info->subdev[0].mtd; ret = 0; } else if (info->num_subdev > 1) { - struct mtd_info *cdev[nr]; + struct mtd_info **cdev; + + cdev = kmalloc_array(nr, sizeof(*cdev), GFP_KERNEL); + if (!cdev) { + ret = -ENOMEM; + goto err; + } + /* * We detected multiple devices. Concatenate them together. */ @@ -230,6 +237,7 @@ static struct sa_info *sa1100_setup_mtd(struct platform_device *pdev, info->mtd = mtd_concat_create(cdev, info->num_subdev, plat->name); + kfree(cdev); if (info->mtd == NULL) { ret = -ENXIO; goto err;