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