LKML Archive on
help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Kees Cook <>
Cc: Linux Kernel Mailing List <>,
	Dan Carpenter <>,
	Silvio Cesare <>,
	Matthew Wilcox <>
Subject: Re: [GIT PULL] overflow updates (part 2) for v4.18-rc1
Date: Tue, 12 Jun 2018 18:44:37 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20180612233552.GA25041@beast>

On Tue, Jun 12, 2018 at 4:36 PM Kees Cook <> 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

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


  reply	other threads:[~2018-06-13  1:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-12 23:35 Kees Cook
2018-06-13  1:44 ` Linus Torvalds [this message]
2018-06-13 19:07   ` Kees Cook

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \
    --subject='Re: [GIT PULL] overflow updates (part 2) for v4.18-rc1' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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