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 S1760389AbdJQSlh (ORCPT <rfc822;w@1wt.eu>);
        Tue, 17 Oct 2017 14:41:37 -0400
Received: from mout.web.de ([212.227.15.3]:53593 "EHLO mout.web.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753165AbdJQSle (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 17 Oct 2017 14:41:34 -0400
Subject: Re: char/tpm: Improve a size determination in nine functions
To: Mimi Zohar <zohar@linux.vnet.ibm.com>, linux-integrity@vger.kernel.org,
        linuxppc-dev@lists.ozlabs.org
Cc: Julia Lawall <julia.lawall@lip6.fr>,
        Alexander Steffen <Alexander.Steffen@infineon.com>,
        linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Corentin Labbe <clabbe.montjoie@gmail.com>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
        Jerry Snitselaar <jsnitsel@redhat.com>,
        Kenneth Goldman <kgold@linux.vnet.ibm.com>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Nayna Jain <nayna@linux.vnet.ibm.com>,
        Paul Mackerras <paulus@samba.org>,
        =?UTF-8?Q?Peter_H=c3=bcwe?= <PeterHuewe@gmx.de>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>
References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net>
 <83a166af-aecc-649d-dfe3-a72245345209@users.sourceforge.net>
 <1508238182.16112.475.camel@linux.intel.com>
 <c8d37c0407a949c1abb35cfd79c17f58@infineon.com>
 <1508244757.4234.60.camel@linux.vnet.ibm.com>
 <alpine.DEB.2.20.1710171456360.5035@hadrien>
 <1508253453.4234.81.camel@linux.vnet.ibm.com>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Message-ID: <9689f036-ba9f-d23b-cf89-c289bc308771@users.sourceforge.net>
Date: Tue, 17 Oct 2017 20:41:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1508253453.4234.81.camel@linux.vnet.ibm.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:Rdfw71FmHZdWRwAfyb3lIglJPbistfHhRIKssS48z02OoV666A5
 jI3SIIE2jvoN7MU+R3mTtayQ0e0u+pdxh4r+FB3gfmi+f/SCn+FY7R9vURYh1WzP08bn/dI
 0wo3O7oLcuydD9spRyhUYSq4yAoyYXbg38F0a05Xwi0PPU1KJpYp/dREPF7AUfvKP3fN305
 mTm//wm5qz5LtUEjTJLmw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Wg6S1/Osmeo=:PcNfGC3iUgv8KyYKwaN9du
 Mo7nKy27fGolZagk2RyIFF/x8hamjD7r7CE4JFIKVHsojvTy08eq1d1puZOEUSYbsz0q2J16e
 JZ5Bp2RAT42OeUFnxGIhwPeOznz6cwkF2MZk9q4hmq26A/QUdIvxuSAPZHDoXF/ZUSTbmXd6D
 8mDbMl9cvtKSj3wbNP5i8+8iGEyqocLlKTfSqQ1kNJh3tSmyxBu+F/y1wFDgMGgL1q44U//1w
 CktYMSHXUcQB74S4gCP5YLEyed0Jmx+SKzUPr0rjLmBhHWXWfnVLrEum1FuPgvXf0mM7u9DKJ
 2/olq2wFtKJCtUQC6KxwfUzGQJGL4hNWOuQSt98bQisho42fokMFq0XapV1OIyKWcYKUBQ6DQ
 El0V+szwMIo6hxETzy/4WDpkRErJFppzrZ3NjlOthvxPiBVP9x/QW7eVDEQNaVxFLinrCMpLV
 BVZouD/cpxJrvKLqVBlZN7BZ9O/dbuXIK9xqcK+yAAvy5g1o7PFa8XCihRoDbMT6gqo1uPhT3
 Z0Y0FDR2lV5wH2K9WKcd57QnpdD+AOrqjW2l+xDlVk4MFdRhxyRMZy8oab861MkAk3k6uh8TR
 u46lEAz/44tK3uTu/9rAms9JIA4UE/PZjTVCXYZ9rFQkFflXPBDMougOiLa4EtYUFW3ZeFphM
 gVieffc3YpkjMngY9Yy05iB3SOH0esF/2yFbZgIYFA3y6DEJ09S7RzzAJBWglKxQSOoKhsid3
 3zQZ/FtaSvLZlbQTk//jupEPqUuMVnRro0hJj8UbSf/Sj1wEHy+mi/3cXRk3tXjfd+5CY4Ijz
 Jgh0H72WDYM+ZtTv7QlVz6oxPQWGPWMrFAISxTe7ZlE8y4b+F8=
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> 	p = kmalloc(sizeof(*p), ...);
>>
>> The alternative form where struct name is spelled out hurts readability and
>> introduces an opportunity for a bug when the pointer variable type is changed
>> but the corresponding sizeof that is passed to a memory allocator is not.
> 
> True, thanks for the reminder.

Will it trigger further software development considerations (besides my contributions)?


> Is this common in new code?

Do you start an official survey here?


> Is there a script/ or some other automated way of catching this usage

Yes. - I am using an approach for the semantic patch language.   ;-)


> before patches are upstreamed?

I imagine that a corresponding source code analysis variant could be applied
in more cases if sufficient acceptance could be achieved.


> Just as you're doing here, the patch description should reference this
> in the patch description.

Do you find my wording “This issue was detected by using the Coccinelle software.” insufficient?

Regards,
Markus