From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Date: Tue, 17 Oct 2017 15:57:13 +0000 Subject: Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations Message-Id: <1508255833.3129.33.camel@HansenPartnership.com> List-Id: References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <20171016183139.otyh3m5c5yurtmow@linux.intel.com> <20171016183512.3bz6x4b6lbhpbkje@linux.intel.com> <20171017085124.pkrjzghcf5wmcydc@mwanda> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: SF Markus Elfring , Dan Carpenter , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: Jarkko Sakkinen , Andy Shevchenko , Benjamin Herrenschmidt , Corentin Labbe , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , Peter =?ISO-8859-1?Q?H=FCwe?= , Stefan Berger , LKML , kernel-janitors@vger.kernel.org On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote: > > > > Fixes is only for bug fixes.  These don't fix any bugs. > > How do you distinguish these in questionable source code > from other error categories or software weaknesses? A style change is one that doesn't change the effect of the execution.  These don't actually even change the assembly, so there's programmatic proof they're not fixing anything. Bug means potentially user visible fault.  In any bug fix commit you should document the fault and its effects on users so those backporting can decide if they care or not. James From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yGg3M5wJWzDqF9 for ; Wed, 18 Oct 2017 03:03:43 +1100 (AEDT) Message-ID: <1508255833.3129.33.camel@HansenPartnership.com> Subject: Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations From: James Bottomley To: SF Markus Elfring , Dan Carpenter , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: Jarkko Sakkinen , Andy Shevchenko , Benjamin Herrenschmidt , Corentin Labbe , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , Peter =?ISO-8859-1?Q?H=FCwe?= , Stefan Berger , LKML , kernel-janitors@vger.kernel.org Date: Tue, 17 Oct 2017 08:57:13 -0700 In-Reply-To: References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <20171016183139.otyh3m5c5yurtmow@linux.intel.com> <20171016183512.3bz6x4b6lbhpbkje@linux.intel.com> <20171017085124.pkrjzghcf5wmcydc@mwanda> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote: > > > > Fixes is only for bug fixes.  These don't fix any bugs. > > How do you distinguish these in questionable source code > from other error categories or software weaknesses? A style change is one that doesn't change the effect of the execution.  These don't actually even change the assembly, so there's programmatic proof they're not fixing anything. Bug means potentially user visible fault.  In any bug fix commit you should document the fault and its effects on users so those backporting can decide if they care or not. James