lkml.org 
[lkml]   [2018]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] overflow updates (part 2) for v4.18-rc1
On Tue, Jun 12, 2018 at 4:36 PM Kees Cook <keescook@chromium.org> wrote:
>
> - Treewide conversions of allocators to use either 2-factor argument
> variant when available, or array_size() and array3_size() as needed (Kees)

Ok, some of this smells just a tad too much of automation, but I've
done the pull and it's going through my build tests.

Example nonsensical conversion:

- res = kzalloc(sizeof(struct resource) * 2, GFP_KERNEL);
+ res = kcalloc(2, sizeof(struct resource), GFP_KERNEL);

which isn't _wrong_, but...

In some of the cases it turns a compile-time constant into a function
call, ie this just makes for bigger and slower code for no reason
what-so-ever.

- ch->tx_array = vzalloc(MIC_DMA_DESC_RX_SIZE * sizeof(*ch->tx_array));
+ ch->tx_array = vzalloc(array_size(MIC_DMA_DESC_RX_SIZE,
+ sizeof(*ch->tx_array)));

At least in the kzalloc/kcalloc conversion it results in more legible code.

The array_size() conversions, in contrast, actually result in *LESS*
legible code, in worse code generation, and absolutely no upside for
cases like the above.

To make up for it, there's some conversions *away* from nonsensical expressions:

- hc_name = kzalloc(sizeof(char) * (HSMMC_NAME_LEN + 1), GFP_KERNEL);
+ hc_name = kzalloc(HSMMC_NAME_LEN + 1, GFP_KERNEL);

but I _really_ think you were way too eager to move to array_size()
even when it made no sense what-so-ever.

But at least with the kcalloc()/kmalloc_array() conversions now
preferred, those crazy cases are now a minority rather than "most of
the patch makes code worse".

I am *not* looking forward to the conflicts this causes, but maybe it
won't be too bad. Fingers crossed.

Linus

\
 
 \ /
  Last update: 2018-06-13 03:44    [W:0.068 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site