Received: by 10.213.65.68 with SMTP id h4csp38756imn; Mon, 12 Mar 2018 16:42:07 -0700 (PDT) X-Google-Smtp-Source: AG47ELt46/xDDG4Mc4px07tWnu4zMn7TrDgp26ka/kZo9aIkuH4eFSTwwmcHKvNmkWs7luZoGrQn X-Received: by 2002:a17:902:3001:: with SMTP id u1-v6mr9575473plb.254.1520898127312; Mon, 12 Mar 2018 16:42:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520898127; cv=none; d=google.com; s=arc-20160816; b=WWVE3B2kr62IO+yW0KtQ0OanW3TA8Xf/dJGMgMilKMbBoPVSFMsK3NzyfqQiJbSt7H vJVnxRTGF/bvqxU9ZR1FjRcplzZ1xnpt7uTLz0wsDX1hgpMMdOQDjTsWG3dkw5gKfGPJ 1UYhVFfTt84xnWecCqq6N0+BCPFO3m9DFKB4EY9wMJZIqbeoz54poMKu6anVGqyzCOCY kWRkbC6bwWsTCCygjONgPapecUHhxux0SWGJpMe7DsF3FdiUz7FrSY+4GFEfH2uEuu/A 11KutARiR7Xv97wZXg1puQ2hskKQ+pA5cs34a96dNEBpNw17SoqyV/2JB30kbVNkqDkJ 4G8w== 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=Ra8RzQ6NF3WoJWHoLHJZC52OVd80crpXYQfrAlX5uo8=; b=DpU3POTQLUUkUp1Qa8gCvrCxAe8aXp9hIeSqcuL3cRQWiVKTGbMvRiD17XsNQt6QDG Ao7BAr2LIQut3+yvF59HpCe6bhjfPGk5HDsM4dGTVVh2GEBJoekEAFmNOGJbveUIYYkm b3QcE+/QBb9TjO94dcVj42kppC7CUH6szqH4IZIJbrai8VT2YLUX034nveqw2QYhCqAK yOc9khAN5S4M5yJ7Wq7N8FLfLdPCbMYl2S+gLCCbRFJjytp2He+YZuI6fUyvFQaVJkLV Uz6k65UH3ebKtC5c3bfTWu7zaUaWknpQ69aS0ls1/BrOcplkxGw+XlnlPAf/Q4b+evk1 gFYA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 62si6710481pfh.153.2018.03.12.16.41.53; Mon, 12 Mar 2018 16:42:07 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932364AbeCLXk4 (ORCPT + 99 others); Mon, 12 Mar 2018 19:40:56 -0400 Received: from mail-pg0-f47.google.com ([74.125.83.47]:42998 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932322AbeCLXkx (ORCPT ); Mon, 12 Mar 2018 19:40:53 -0400 Received: by mail-pg0-f47.google.com with SMTP id x2so3054494pgo.9 for ; Mon, 12 Mar 2018 16:40:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ra8RzQ6NF3WoJWHoLHJZC52OVd80crpXYQfrAlX5uo8=; b=I2CeIMc7RdYoIcU5RZ0H74EydNMI3j7Yd2h5bFjBQYjbFlDaX16q/gFIfmmJc2XIR6 ObKJ9I8HpVN5rFpelubb3mS8AQj4f0MziBkxzegVRrw4oLV2JZPC1iRBfWFTlzVw++R8 sq4AdOOJGnXaTLi2Z6LBCNVSJeD8Oyls1llGSZqE1bIKvhm3FtYyKJFLykFpcrYghQWA 8dvFHTRhA1O7F74wk3zU40TzwFoOL4R1dOlrtVubmDT8503jJlAbVgPvBvZaQWWG3xIz BXtqdVTad1f2GBqBcPWTclXbO/LrPriYLBN/4edKnleJTW2tJWa8GesTcoqybOk9yCOZ iALA== X-Gm-Message-State: AElRT7Hfz9sU6tFJ5Vv+zPc5VBQPxEAcd5HySwM5OLrZYr6+13hAvOMe 08TL7edybQpOMKiKaSckd5P+UzvUYlo= X-Received: by 10.99.190.15 with SMTP id l15mr8192164pgf.325.1520898052567; Mon, 12 Mar 2018 16:40:52 -0700 (PDT) Received: from ?IPv6:2601:602:9802:a8dc::b761? ([2601:602:9802:a8dc::b761]) by smtp.gmail.com with ESMTPSA id d186sm19217297pfd.1.2018.03.12.16.40.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 16:40:51 -0700 (PDT) Subject: Re: [PATCH 1/4] gpio: Remove VLA from gpiolib To: Rasmus Villemoes , Linus Walleij , Kees Cook Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Lukas Wunner , Mathias Duckeck , Nandor Han , Semi Malinen , Patrice Chotard References: <20180310001021.6437-1-labbott@redhat.com> <20180310001021.6437-2-labbott@redhat.com> From: Laura Abbott Message-ID: <301ecaf7-62a4-14af-3a5b-7bd76a49c4f6@redhat.com> Date: Mon, 12 Mar 2018 16:40:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/12/2018 08:00 AM, Rasmus Villemoes wrote: > On 2018-03-10 01:10, Laura Abbott wrote: >> /* collect all inputs belonging to the same chip */ >> first = i; >> - memset(mask, 0, sizeof(mask)); >> + memset(mask, 0, sizeof(*mask)); > > see below > >> @@ -2887,14 +2909,30 @@ void gpiod_set_array_value_complex(bool raw, bool can_sleep, >> >> while (i < array_size) { >> struct gpio_chip *chip = desc_array[i]->gdev->chip; >> - unsigned long mask[BITS_TO_LONGS(chip->ngpio)]; >> - unsigned long bits[BITS_TO_LONGS(chip->ngpio)]; >> + unsigned long *mask; >> + unsigned long *bits; >> int count = 0; >> >> + mask = kmalloc_array(BITS_TO_LONGS(chip->ngpio), >> + sizeof(*mask), >> + can_sleep ? GFP_KERNEL : GFP_ATOMIC); >> + >> + if (!mask) >> + return; >> + >> + bits = kmalloc_array(BITS_TO_LONGS(chip->ngpio), >> + sizeof(*bits), >> + can_sleep ? GFP_KERNEL : GFP_ATOMIC); >> + >> + if (!bits) { >> + kfree(mask); >> + return; >> + } >> + >> if (!can_sleep) >> WARN_ON(chip->can_sleep); >> >> - memset(mask, 0, sizeof(mask)); >> + memset(mask, 0, sizeof(*mask)); > > Hm, it seems you're now only clearing the first word of mask, not the > entire allocation. Why not just use kcalloc() instead of kmalloc_array > to have it automatically cleared? > Bleh, I didn't think through that carefully. I'll just switch to kcalloc, especially since it calls kmalloc_array. > Other random thoughts: maybe two allocations for each loop iteration is > a bit much. Maybe do a first pass over the array and collect the maximal > chip->ngpio, do the memory allocation and freeing outside the loop (then > you'd of course need to preserve the memset() with appropriate length > computed). And maybe even just do one allocation, making bits point at > the second half. > I was trying to make minimal changes and match the existing code. Is this likely to be an actual hot path to optimize? > Does the set function need to be updated to return an int to be able to > inform the caller that memory allocation failed? > That would involve changing the public API. I don't have a problem doing so if that's what you want. > Rasmus > Thanks, Laura