linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Laura Abbott <labbott@redhat.com>,
	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: Tue, 13 Mar 2018 08:23:22 +0100	[thread overview]
Message-ID: <a55d544e-0b0c-1a5a-b474-d31eb338e8ee@rasmusvillemoes.dk> (raw)
In-Reply-To: <301ecaf7-62a4-14af-3a5b-7bd76a49c4f6@redhat.com>

On 2018-03-13 00:40, Laura Abbott wrote:
> On 03/12/2018 08:00 AM, Rasmus Villemoes wrote:
>>
>> 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.

Well, textually you may be making the minimal changes (though the error
handling adds some "boilerplate" kfree()s etc.), but semantically adding
two kmallocs in a loop could be a big deal. Dunno, maybe in practice all
the gpios (almost always) belong to the same chip, so there's only one
iteration through the loop anyway.

> Is this likely to be an actual hot path to optimize?

No idea, it was just a drive-by comment, so also...

>> 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.

... I don't "want" anything, that'll be for the gpio maintainers to decide.

Rasmus

  reply	other threads:[~2018-03-13  7:23 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
2018-03-13  7:23       ` Rasmus Villemoes [this message]
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=a55d544e-0b0c-1a5a-b474-d31eb338e8ee@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).