From: Laura Abbott <labbott@redhat.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Linus Walleij <linus.walleij@linaro.org>,
Kees Cook <keescook@chromium.org>
Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-hardening@lists.openwall.com,
Lukas Wunner <lukas@wunner.de>,
Mathias Duckeck <m.duckeck@kunbus.de>,
Nandor Han <nandor.han@ge.com>,
Semi Malinen <semi.malinen@ge.com>,
Patrice Chotard <patrice.chotard@st.com>
Subject: Re: [PATCH 1/4] gpio: Remove VLA from gpiolib
Date: Mon, 12 Mar 2018 16:40:50 -0700 [thread overview]
Message-ID: <301ecaf7-62a4-14af-3a5b-7bd76a49c4f6@redhat.com> (raw)
In-Reply-To: <a758ce3f-fed7-2ecf-94c5-ba133ea75bde@rasmusvillemoes.dk>
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
next prev parent reply other threads:[~2018-03-12 23:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-10 0:10 [PATCH 0/4] VLA removal from the GPIO subsystem Laura Abbott
2018-03-10 0:10 ` [PATCH 1/4] gpio: Remove VLA from gpiolib Laura Abbott
2018-03-12 15:00 ` Rasmus Villemoes
2018-03-12 23:40 ` Laura Abbott [this message]
2018-03-13 7:23 ` Rasmus Villemoes
2018-03-17 8:25 ` Lukas Wunner
2018-03-18 14:23 ` Lukas Wunner
2018-03-18 20:34 ` Rasmus Villemoes
2018-03-19 7:00 ` Lukas Wunner
2018-03-19 15:09 ` Andy Shevchenko
2018-03-28 0:37 ` Laura Abbott
2018-03-28 3:54 ` Lukas Wunner
2018-03-10 0:10 ` [PATCH 2/4] gpio: Remove VLA from MAX3191X driver Laura Abbott
2018-03-26 9:07 ` Linus Walleij
2018-03-10 0:10 ` [PATCH 3/4] gpio: Remove VLA from xra1403 driver Laura Abbott
2018-03-12 6:06 ` EXT: " Nandor Han
2018-03-26 9:09 ` Linus Walleij
2018-03-28 7:27 ` Geert Uytterhoeven
2018-03-28 17:27 ` Laura Abbott
2018-04-04 12:53 ` Linus Walleij
2018-03-10 0:10 ` [PATCH 4/4] gpio: Remove VLA from stmpe driver Laura Abbott
2018-03-13 9:13 ` Phil Reid
2018-03-14 0:18 ` Laura Abbott
2018-03-14 1:16 ` Laura Abbott
2018-03-14 2:55 ` Phil Reid
2018-03-13 9:42 ` [PATCH 0/4] VLA removal from the GPIO subsystem Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=301ecaf7-62a4-14af-3a5b-7bd76a49c4f6@redhat.com \
--to=labbott@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lukas@wunner.de \
--cc=m.duckeck@kunbus.de \
--cc=nandor.han@ge.com \
--cc=patrice.chotard@st.com \
--cc=semi.malinen@ge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).