[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5j+Wv7YXJRm-9kYCSLQbkWoXTXJKU++qsVUrjOUDGg4rpg@mail.gmail.com>
Date: Wed, 7 Sep 2016 10:01:27 -0700
From: Kees Cook <keescook@...omium.org>
To: Joe Perches <joe@...ches.com>
Cc: SF Markus Elfring <elfring@...rs.sourceforge.net>,
Paolo Bonzini <pbonzini@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
"x86@...nel.org" <x86@...nel.org>, Dave Young <dyoung@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Matt Fleming <matt.fleming@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org,
Julia Lawall <julia.lawall@...6.fr>
Subject: Re: x86-ksysfs: Use kmalloc_array() in create_setup_data_nodes()
On Wed, Sep 7, 2016 at 9:37 AM, Joe Perches <joe@...ches.com> wrote:
> On Wed, 2016-09-07 at 09:23 -0700, Kees Cook wrote:
>> Fixing these kmalloc calls would be a nice thing to clean up
>> everywhere.
>
> Dubious as gcc cannot currently optimize known small fixed size
> allocations with alloc_array and will always perform the
> multiplication.
Oh, that's sad. Is it not able to tell what the types are to basic
overflow validation? Could we help gcc in some way?
> Also the style of sizeof(*ptr) is not always as clear, obvious
> nor as easy to grep as sizeof(type).
I've always been on the fence about this (I like being able to see
destination:thing, sizeof(*thing) for easy scanning), but having the
type right there can be easier for text searches.
-Kees
--
Kees Cook
Nexus Security
Powered by blists - more mailing lists