Received: by 10.213.65.68 with SMTP id h4csp1186918imn; Sun, 18 Mar 2018 18:41:06 -0700 (PDT) X-Google-Smtp-Source: AG47ELuMvUY1vt1vS5cQrTRzUjfIFoWGcDALQ7qshPvb5cEpwFknClGkahuo49qK12wBcUx7+Qwv X-Received: by 10.98.186.2 with SMTP id k2mr8642411pff.225.1521423666897; Sun, 18 Mar 2018 18:41:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521423666; cv=none; d=google.com; s=arc-20160816; b=VExpHMvuRPwZCCxGPHH9ZbQ2eqQzyfqoGTXOJY2TLlYBrV2fWIm2atRgtWjaj6Qq0X p0kzbcMeRWoZmoz1h4y8wWfOpJJ0nmz68AysbctnGrNXY1PLuLCpNhr4x5tmA0EQhrEQ Oczk/mY3dT2PiKYF8NaiVFjVoYbcQy++NyoadCZJoF2a5NjC1Rs5rNaffISuhUIq5vrp 7kCe7ByK/cp7Guw6tn1z7MliW8et0mz/pPTc31LH6Q6GbmMezXYUApxo/yOFCmvbdbNq oOHDaLmFpD1GieoLyWmFDUtPr+DPT/06wRzrQfaV4rVO4tXXYqhfE/lBuh5V+as47RAl iqrQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=3Hicz3seT4Ptw1cYWrt1bMs9ADkVupAMZbNkdc9DXVw=; b=tu7DZ5AsBEQZvKiZGm3RzzuMaiAMZ8ViJh4jT1mV/OEwFjZWHjxXNsNQT18L4owZeV Fgc0fT7mmVEoTsn6AD1fkdXI8/5kwWJPTUBpT+kbsSghC7JBUo+kvRPfMKUWOeT8qPT9 6ra810RPYlHvSlOwNmLcgfCvvGctpLLMfON+o8E3bkrjUXHbbMMdUjTJ9mp6xUL9tOhJ OP/G0KC5lyQrkYS45WqfJ0aMWaazBshzbcU17IBG0qierfAAYvzAOVqU0wZVvvu8i6Js +SwAvEV/PFK0AYFK3w52ARr/4fLYw1lwhjAyeDi93gaIDIqEKkpm+naBD1BIJd4daSuG Nomw== 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 l184si8667499pga.525.2018.03.18.18.40.50; Sun, 18 Mar 2018 18:41:06 -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 S1755014AbeCSBaG (ORCPT + 99 others); Sun, 18 Mar 2018 21:30:06 -0400 Received: from anchovy3.45ru.net.au ([203.30.46.155]:48351 "EHLO anchovy3.45ru.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754783AbeCSBaE (ORCPT ); Sun, 18 Mar 2018 21:30:04 -0400 Received: (qmail 20231 invoked by uid 5089); 19 Mar 2018 01:30:02 -0000 Received: by simscan 1.2.0 ppid: 20160, pid: 20161, t: 0.0444s scanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.88.3/m:40/d:1950 Received: from unknown (HELO ?192.168.0.122?) (preid@electromag.com.au@203.59.235.95) by anchovy2.45ru.net.au with ESMTPA; 19 Mar 2018 01:30:01 -0000 Subject: Re: [PATCHv2 4/4] gpio: Remove VLA from stmpe driver To: Laura Abbott , Linus Walleij , Kees Cook , Patrice Chotard Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com References: <20180315180030.20001-1-labbott@redhat.com> <20180315180030.20001-5-labbott@redhat.com> From: Phil Reid Message-ID: <21a2e869-62fb-75ef-ae7b-a27e136696f7@electromag.com.au> Date: Mon, 19 Mar 2018 09:29:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180315180030.20001-5-labbott@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-AU Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/03/2018 02:00, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) > > This patch replaces a VLA with an appropriate call to kmalloc_array. > > Signed-off-by: Laura Abbott > --- > v2: Switch to GFP_KERNEL. There was some discussion about if we should > be doing the allocation at all but given a) the allocation is pretty > small and b) we can possibly take a mutex in a called function I think > this is fine. I still think it's a bad idea. It's simple to preallocate the buffer. But it's up to the maintainer. > --- > drivers/gpio/gpio-stmpe.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpio-stmpe.c b/drivers/gpio/gpio-stmpe.c > index f8d7d1cd8488..c2bb20ace6f5 100644 > --- a/drivers/gpio/gpio-stmpe.c > +++ b/drivers/gpio/gpio-stmpe.c > @@ -369,10 +369,14 @@ static irqreturn_t stmpe_gpio_irq(int irq, void *dev) > struct stmpe *stmpe = stmpe_gpio->stmpe; > u8 statmsbreg; > int num_banks = DIV_ROUND_UP(stmpe->num_gpios, 8); > - u8 status[num_banks]; > + u8 *status; > int ret; > int i; > > + status = kmalloc_array(num_banks, sizeof(*status), GFP_KERNEL); > + if (!status) > + return IRQ_NONE; > + > /* > * the stmpe_block_read() call below, imposes to set statmsbreg > * with the register located at the lowest address. As STMPE1600 > @@ -424,6 +428,7 @@ static irqreturn_t stmpe_gpio_irq(int irq, void *dev) > } > } > > + kfree(status); > return IRQ_HANDLED; > } > > -- Regards Phil Reid