Received: by 10.192.165.148 with SMTP id m20csp12212imm; Fri, 20 Apr 2018 02:03:40 -0700 (PDT) X-Google-Smtp-Source: AIpwx48qqqgywp85SD7NBAHYUCbuuYSJOMsY6viaU4OHK5b0fzSQzhw2sIwafee7b1itlAlhpAZD X-Received: by 10.99.169.1 with SMTP id u1mr8118158pge.251.1524215020002; Fri, 20 Apr 2018 02:03:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524215019; cv=none; d=google.com; s=arc-20160816; b=kdcCFI5n4va+5oFIXDFkuxCntSnMPUJojt+jTyDWpp/1vOw3Dqjwo/slQlJIgdB0aA zLaGPxHu2iLnz0azcH2TUA3Tj9mvhIAhA/TmPa1oej4NyEJLyTyc+ozUG9kjbwSMoV4n OnCiybiP8Ho46iLlyYwNeZkzck46ABOW4LdGLh7WMcfZb82h8YeYze4s/ptJdn8Rx3vU 8ZckY2BTnjIy5eQ/RWnYtnG70jbii84cCOug4kS0WC/QJ4fyiWTT57lB4l69B2t2qO+i fnOOy2So/df292ayOxvWvzWPpAo1u1fSw4RezabiUME6S4+iadmEDFqRi7JkTViq8Q/7 3sPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=y8wsMgBcdIDpkVm9NllLhcZSuOJfWpKxemFUpKGlJWE=; b=FeLT/FF/jjtjWQTH9+TX3O3KrSPgg1chcJBJEoEmjQWVCMHLS4vYWozHxPAc2AVBlR wdMXDtKZ8CVMMTHMNX1VJPnSnoSfuVjPRoq2tZPAcVZMsTrqzoNlCOMUjxc5o02f3RfQ OMwaGFmuQzagaOJkexcRJ5lGtXi76k1VrJsTpleBcZjz7rnSS7/SFow5YXaf7zmyKbIm 7ES1cjNtKbArTxM5g6uPCGPdRb5D+GBtPKjX8eE5gNoVD/FmeXM1dPYPMzXj2vHR5qim reFshYgkHIr9uUyf8S8Wc5j/9Ur+4N0QKSUjA780MOaYNAD/b4XzCGqv8Uuu7LrPkHpb BNJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=FsVogQFQ; 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 w12si4639359pge.165.2018.04.20.02.03.26; Fri, 20 Apr 2018 02:03:39 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=FsVogQFQ; 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 S1754369AbeDTJCK (ORCPT + 99 others); Fri, 20 Apr 2018 05:02:10 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:38739 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754341AbeDTJCG (ORCPT ); Fri, 20 Apr 2018 05:02:06 -0400 Received: by mail-ua0-f194.google.com with SMTP id q38so5251440uad.5; Fri, 20 Apr 2018 02:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y8wsMgBcdIDpkVm9NllLhcZSuOJfWpKxemFUpKGlJWE=; b=FsVogQFQekfJatV7LEj4gZHXoMsUaXUWD62sDshX7iTHGXn+GDEEO96h48QpwRNNMX PKzsBtQCFEq66SYVoreR0M2ZllN7cUOhB+LN/lvNoqFp4FEnkmDieLu+m/1oP/EAYmAE KkeRf32ATHQeIF3XoP5fb85uFwcDNyn46Wy24KchCLySOUMNSo/0SWopG8KzedCo+0Hl HuNLpIwhwfkJG9lQFo0XZ0aaX020ZR8FAhcI5BS1746mJXXPMElmKInXOPQlv2Na+AH8 F2Yw9RD3+D36bO23O0qty5iROHcvbfFdw+he3uNnPILRMgEgpcP3inFSr0Y/NbuRjPm1 zFCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=y8wsMgBcdIDpkVm9NllLhcZSuOJfWpKxemFUpKGlJWE=; b=KQwyFoFefuYGVeyLhlvbIzy6JUyaF6C0EvZMZT2JvKbfn/mJerKsTpM64/SxUf7fgQ X7tRCJUFXHpgHXG4W+vG9VwxAXULf/RtwJ48moQkgzTQeiKXov82uDatuYCUtexsl+5N 9Jbyr9wiYiIdfshSfJeM1mqhi2z8kcPTiP/04wInY99cWZ+QkrGvA4Leyu0t6QTWs3H7 QDYwj2hgFx5C3wKQ924n+L3wBnId9moB5E0ivvIWZ+BMem8vQ3Wfwnakc4IIMdc5Dm/M teDwvFYzBdB/gFviNbCeObIrD+UxpxDOhwgVtBSsw8mU+hLDLOxjS2nZboW6fQAbrQBQ wmqg== X-Gm-Message-State: ALQs6tDIACj4nw1gPdl/hg0zG0vB5RXGwt7ku6JpkRf+kTIn5pk6/L9U s63PLHMioHeCEITl1LaJFEN4L89mZxD2ucNXWMU= X-Received: by 10.176.82.50 with SMTP id i47mr7168272uaa.12.1524214925105; Fri, 20 Apr 2018 02:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.122.68 with HTTP; Fri, 20 Apr 2018 02:02:04 -0700 (PDT) In-Reply-To: <20180413212427.18261-1-labbott@redhat.com> References: <20180413212427.18261-1-labbott@redhat.com> From: Geert Uytterhoeven Date: Fri, 20 Apr 2018 11:02:04 +0200 X-Google-Sender-Auth: hq-dpDU4cKcuJiNdN5KTct7Ks8Y Message-ID: Subject: Re: [PATCHv5] gpio: Remove VLA from gpiolib To: Laura Abbott Cc: Linus Walleij , Kees Cook , Lukas Wunner , Rasmus Villemoes , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , kernel-hardening@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laura, Thanks for your patch! On Fri, Apr 13, 2018 at 11:24 PM, Laura Abbott wrote: > The new challenge is to remove VLAs from the kernel > (see https://lkml.org/lkml/2018/3/7/621) to eventually > turn on -Wvla. > > Using a kmalloc array is the easy way to fix this but kmalloc is still > more expensive than stack allocation. Introduce a fast path with a > fixed size stack array to cover most chip with gpios below some fixed > amount. The slow path dynamically allocates an array to cover those > chips with a large number of gpios. Blindly replacing VLAs by allocated arrays is IMHO not such a good solution. On the largest systems, NR_GPIOS is 2048, so that makes 2 arrays of 256 bytes. That's an uppper limit, and assumes they are all on the same gpiochip, which they probably aren't. Still, 2 x 256 bytes is a lot, so I agree it should be fixed. So, wouldn't it make more sense to not allocate memory, but just process the request in chunks (say, at most 128 gpios per chunk, i.e. 2 x 16 bytes)? The code already caters for handling chunks due to not all gpios belonging to the same gpiochip. That will probably also be faster than allocating memory, which is the main idea behind this API. > Reviewed-and-tested-by: Lukas Wunner > Signed-off-by: Lukas Wunner > Signed-off-by: Laura Abbott > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1192,6 +1196,10 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data, > goto err_free_descs; > } > > + if (chip->ngpio > FASTPATH_NGPIO) > + chip_warn(chip, "line cnt %d is greater than fast path cnt %d\n", > + chip->ngpio, FASTPATH_NGPIO); FWIW, can this warning be triggered from userspace? > @@ -2662,16 +2670,28 @@ int gpiod_get_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)]; Hence just use a fixed size here... > + unsigned long fastpath[2 * BITS_TO_LONGS(FASTPATH_NGPIO)]; > + unsigned long *mask, *bits; > int first, j, ret; > > + if (likely(chip->ngpio <= FASTPATH_NGPIO)) { > + memset(fastpath, 0, sizeof(fastpath)); > + mask = fastpath; > + bits = fastpath + BITS_TO_LONGS(FASTPATH_NGPIO); > + } else { > + mask = kcalloc(2 * BITS_TO_LONGS(chip->ngpio), > + sizeof(*mask), > + can_sleep ? GFP_KERNEL : GFP_ATOMIC); > + if (!mask) > + return -ENOMEM; > + bits = mask + BITS_TO_LONGS(chip->ngpio); > + } > + > if (!can_sleep) > WARN_ON(chip->can_sleep); > > /* collect all inputs belonging to the same chip */ > first = i; > - memset(mask, 0, sizeof(mask)); > do { > const struct gpio_desc *desc = desc_array[i]; > int hwgpio = gpio_chip_hwgpio(desc); Out-of-context, the code does: | __set_bit(hwgpio, mask); | i++; | } while ((i < array_size) && ... and change this limit to "(i < min(array_size, first + ARRAY_SIZE(mask) * BITS_PER_BYTE))" | (desc_array[i]->gdev->chip == chip)); ... and you're done? > @@ -2878,7 +2904,7 @@ static void gpio_chip_set_multiple(struct gpio_chip *chip, > } > } > > -void gpiod_set_array_value_complex(bool raw, bool can_sleep, > +int gpiod_set_array_value_complex(bool raw, bool can_sleep, Same here. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds