From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1035759AbdD1KtY (ORCPT ); Fri, 28 Apr 2017 06:49:24 -0400 Received: from mout.web.de ([212.227.15.14]:64716 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032028AbdD1KtQ (ORCPT ); Fri, 28 Apr 2017 06:49:16 -0400 Subject: Re: [alsa-devel] [PATCH 1/3] ASoC: simple-card: Use devm_kcalloc() in asoc_simple_card_parse_aux_devs() To: Alexandre Belloni Cc: alsa-devel@alsa-project.org, Jaroslav Kysela , Kuninori Morimoto , Liam Girdwood , Mark Brown , Nikita Yushchenko , Takashi Iwai , kernel-janitors@vger.kernel.org, LKML References: <8b5e37d1-17c5-4551-801f-ca7939d5efd7@users.sourceforge.net> <8c8c6979-0368-9ef5-2e10-57199f0bc03e@users.sourceforge.net> <20170428085735.i7xpxph24t5v5f5q@piout.net> From: SF Markus Elfring Message-ID: <49bbbcac-f970-bbb9-c66b-c9c25229cc6a@users.sourceforge.net> Date: Fri, 28 Apr 2017 12:48:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170428085735.i7xpxph24t5v5f5q@piout.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:qx7+FATleIowkS9EIaBytXhzAhLtU9WZpM1053y9U8Kd/6mGvRT IDZZLzkU5YwsKwux78+pIhEJX6F3U90JVNoz91Jp+OR9+N5RPOiUWIuDWYAZeBP7GLA2A8d z9KIXK/EUk+u+TwwF1ploHBYcf9ibOnjZshdA0dAy1CkN7e4FwoUmGWOH/7+G5iMiqt24wo EMyTvfFCB1bbvk7ODV9Bg== X-UI-Out-Filterresults: notjunk:1;V01:K0:xvUQ1zd+63I=:5LhCqgbeMEaU8vn/vkAUC5 DniukiDkZfU0ooZr19cYtCbSaniZJe1A5r6Bc0g/0PIdP4FlKmwGaNTuiT241OKRb4t+PMCm+ ehuQBKlCSDjY7HPqXIsAQmouqKspJxyDLrqFsP9EZmI629OBmFcmCP5lqAK35ww7APBkfDGRE Ca8flTSvmazoXXOcwbl8Nv0B7WV1p36UrzBp7Z7HRngSdn2jnlEhRIvt2yC8m+i6xkOmYQVcm DQBTYEWDsnfj59I5wsfJgjcmDSVOTngRUrJltaPr4MFGTsyd/T8ZRpCyqwfZWPAutwbVEI0rq OrsB+xeDS5Bg+lg91HzB0n8jGkOxUAUN9QIY6xMcRSosp1fVeObImj3fMvKir/NEoIMt58dqS HCorSZqCG0vJH+VfUWb7KpOMuPj6JpD8tmUktxpJz5kO7JRLgqz6hv5hXhi/twb1DKZUk35zP sFv2MpUsLc/ynwykzerzDaZpqTikwQnO4pydievbsao2xSts4QRKTDWcNJw5xfAEj/QilcX+q PRctYDz7ONYFX8BTF2gNJek2EaoFEUW0xjMprNuYyL6tIhp0/G829I3Z3FalEUj9d8nKVG6Rp LWY36pdH2tkImsOosQTsw1CnE257/sdNDjfbyPUoYsPsAS8egfA6Xwr3RqdzPkRXKhcprfFct zLfmxfMJyHFrsY/f+HlB1teLsfOT6fr8N54Ky4CBjyHTjNQma22tRhEngOtEP+QYFrbYfv90K X1TbnRNDmWAxu6UCj0VAinSlbtu1EMOv1k46xIr9zYi0ZdC0y4/Zt2bGPLYT/bm1tzPUl3Ev7 fg7X51P Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> @@ -334,8 +334,8 @@ static int asoc_simple_card_parse_aux_devs(struct device_node *node, >> if (n <= 0) >> return -EINVAL; >> >> - card->aux_dev = devm_kzalloc(dev, >> - n * sizeof(*card->aux_dev), GFP_KERNEL); >> + card->aux_dev = devm_kcalloc(dev, n, sizeof(*card->aux_dev), >> + GFP_KERNEL); > > Do you realize that this change has absolutely no value We can have different software development opinions about such a source code adjustment. Does it improve the indentation for the parameters which are passed to this function call? > and just makes the code slower (one more test in the allocation path)? Do we stumble on a target conflict for the shown implementation detail? Does the previous size calculation contain the general possibility for an integer overflow? https://cwe.mitre.org/data/definitions/190.html The value for the variable “len” (and also “n”) might be small enough so that the computed value will usually not exceed the data type limit in this use case. Regards, Markus