From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966026AbdJQThH (ORCPT ); Tue, 17 Oct 2017 15:37:07 -0400 Received: from mga02.intel.com ([134.134.136.20]:11453 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965967AbdJQThF (ORCPT ); Tue, 17 Oct 2017 15:37:05 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,392,1503385200"; d="scan'208";a="910851251" Message-ID: <1508269017.16112.492.camel@linux.intel.com> Subject: Re: char/tpm: Improve a size determination in nine functions From: Andy Shevchenko To: SF Markus Elfring , Mimi Zohar , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: Julia Lawall , Alexander Steffen , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Benjamin Herrenschmidt , Corentin Labbe , Jarkko Sakkinen , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , Peter =?ISO-8859-1?Q?H=FCwe?= , Stefan Berger Date: Tue, 17 Oct 2017 22:36:57 +0300 In-Reply-To: <9689f036-ba9f-d23b-cf89-c289bc308771@users.sourceforge.net> References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <83a166af-aecc-649d-dfe3-a72245345209@users.sourceforge.net> <1508238182.16112.475.camel@linux.intel.com> <1508244757.4234.60.camel@linux.vnet.ibm.com> <1508253453.4234.81.camel@linux.vnet.ibm.com> <9689f036-ba9f-d23b-cf89-c289bc308771@users.sourceforge.net> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.0-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-10-17 at 20:41 +0200, SF Markus Elfring wrote: > > > 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. > > > > 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. So, then instead of still keeping people busy with this noise you better start doing something like CI integration with that for *new* code? I'm pretty sure you may also exercise your achievements on drivers/staging where it would be honored. Have you talked to Fengguang (0-day LKP)? Have you talked to Arnd (I think he is related to kernel-ci)? -- Andy Shevchenko Intel Finland Oy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Date: Tue, 17 Oct 2017 19:36:57 +0000 Subject: Re: char/tpm: Improve a size determination in nine functions Message-Id: <1508269017.16112.492.camel@linux.intel.com> List-Id: References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <83a166af-aecc-649d-dfe3-a72245345209@users.sourceforge.net> <1508238182.16112.475.camel@linux.intel.com> <1508244757.4234.60.camel@linux.vnet.ibm.com> <1508253453.4234.81.camel@linux.vnet.ibm.com> <9689f036-ba9f-d23b-cf89-c289bc308771@users.sourceforge.net> In-Reply-To: <9689f036-ba9f-d23b-cf89-c289bc308771@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: SF Markus Elfring , Mimi Zohar , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: Julia Lawall , Alexander Steffen , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Benjamin Herrenschmidt , Corentin Labbe , Jarkko Sakkinen , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , Peter =?ISO-8859-1?Q?H=FCwe?= , Stefan Berger On Tue, 2017-10-17 at 20:41 +0200, SF Markus Elfring wrote: > > > 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. > > > > 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. So, then instead of still keeping people busy with this noise you better start doing something like CI integration with that for *new* code? I'm pretty sure you may also exercise your achievements on drivers/staging where it would be honored. Have you talked to Fengguang (0-day LKP)? Have you talked to Arnd (I think he is related to kernel-ci)? -- Andy Shevchenko Intel Finland Oy