From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1166429AbdD2IbJ (ORCPT <rfc822;w@1wt.eu>);
        Sat, 29 Apr 2017 04:31:09 -0400
Received: from mout.web.de ([212.227.17.12]:50939 "EHLO mout.web.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1166372AbdD2Ia4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 29 Apr 2017 04:30:56 -0400
Subject: Re: SATA: Fine-tuning for two function implementations
To: Tejun Heo <tj@kernel.org>
Cc: linux-ide@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>, kernel-janitors@vger.kernel.org
References: <df754c7a-2100-7169-0d40-b981ccd952a1@users.sourceforge.net>
 <20170428215334.GH22354@htj.duckdns.org>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Message-ID: <b2a3953b-8e8f-fea1-8a04-9ecafdf31102@users.sourceforge.net>
Date: Sat, 29 Apr 2017 10:30:29 +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: <20170428215334.GH22354@htj.duckdns.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:LkEgthqu8WGjOOuQnj1yJX20I2zwEdwPPL8JhEUrnPuqMs0J/rW
 vLb3SFeXYFuz206hnwAtMV20rgT+cW29FRpy8W63c8pDaz+jOjeFZRYuCrWT1yTF7cI7u8/
 K9yx0+eeQcwZQiuEh5pCJcMn9prAwhpC2IVKpwt6PmRBMGMxwUmpvO46BgPOnp08goU6AJG
 o32Mm5a65B69qNk5b5l+g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:XcJHGRTvTxw=:/B92LAXFbDug26pykYzQsC
 myeLE76L0pNBPEfHzIRPHl6rT4FO2nYqQfr8e8IrY+1bhbXlA8Q2P0i72wB2U9GtZ/zAIMi3a
 AKi0hXWCp2E+p7VV7On6EwFmcUyz9h9qdSL4oCcMJDyNYgSInawaW6piaFGy6HzJNxX9eDVK0
 3Q3PJSftavbI6zFoF8xT4XlLUDBMdeWIMmTjEUm/saWREdPEvRzUf9c8LzlDkm8fJtqJUAmZd
 PY0QPbhU414BFBry/8yVo1P7ozcNrtQB/ofALkZ79PEyYG0uYqZZpO2Wgx1+XJr3s0ASqYquA
 t4kQw7Y5s9JGwuxywZXJX/5qb62xDo4+uW6zK4OzOurt7onCbg36O6VyFgfcrKNipYroDx92Q
 ENpEX75TRHMsGR5+cr8r+WRq5MEtt03wr8mI5WNq7QzDu0KZur6UE/qCG2ghbxki/wHfe3VUj
 v5/sf9DMRVzFWC1J0OCEP1DexN04HqWKvqHUcRkxe91MLSiJ1BG7x2FSLo6PqiyOJfps6BVK+
 sMWqz/1lNJAawYMxI8KuIizE+z0MfOBggV1RhHxSUFlAIfLSNolOECZZJfWvdVEE76ByHvAx4
 3XkEg/WNQgvWSvl03pL4T5IeeisCN0EagncM6AOqpxJBlM4g8IDb8Xly3PJAAtiJ5xLA7rL1Q
 rscJplaIqFezjZUSVxNQ6BmWKN2o05dqNO3OFMNPZD+geJn2ZhbT7Qu+BpTnjkocDsAkgx8KR
 sj2VQCkiIu7O5DeeGo0Z+S9nP4Y32R7ldPW8U8ypB1DAhF+uAyKU+rkyEwg+3s4AGTKst+G96
 /diaGb+
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Hmmm, allocs -> callocs.  Are these actually beneficial?  If so, why?
> Because one multiplication is rolled into the call?

Did the previous size calculations contain the general possibility for
integer overflows?
https://cwe.mitre.org/data/definitions/190.html

* Will the computed values usually stay within the limits of the used
  data types so far?

* How much do you care for corresponding checks and source code annotations
  by functions like “devm_kcalloc”?

Regards,
Markus